There are a number of positions where we attempt to cast a nullable expression to a non-nullable type with something like the following (foo as List<Object?>?)!. This successfully performs the cast and avoids a lint rule which recommends not casting a nullable expression to a non-nullable type. But it can be done more simply. Here are some examples of the improved code:

- data: (result[3] as Map<Object?, Object?>?)!.cast<String, String>(),
+ data: (result[3]! as Map<Object?, Object?>).cast<String, String>(),

- final List<Object?> args = (message as List<Object?>?)!;
+ final List<Object?> args = message! as List<Object?>;

- stringList: (result[13] as List<Object?>?)!.cast<String>(),
+ stringList: (result[13]! as List<Object?>).cast<String>(),

Since we are expecting these values to be non-null, we first null-assert them (!), and then cast the expression with as.

There was previously a helper, _makeGenericCastCall, which generated the String representation for a call to cast, like .cast<Object?>(), which was called in three places. This change consoldiates the surrounding code to those call sites into a new helper, _castValue, which instead returns the complete String of casting a value to a type, possibly null-asserting the value and possibly calling .cast().

Combining all of the casting code into one function also allows us to avoid unnecessary parentheses:

- final String? arg_aString = (args[0] as String?);
+ final String? arg_aString = args[0] as String?;

Improving the nullability-handling allows us to remove the _addGenericTypes helper, and rename the addGenericTypesNullable to just addGenericTypes, since the helper should always print an appropriate nullability suffix.

One prominent change made to the generated code is the removal of "assert foo is not null" statements. These are redundant with the null-asserts (!), although they might offer more information in the assertion message, though I honestly don't think so. The exception thrown by ! has the relevant information in the stack trace.

Fixes flutter/flutter#116972

Pre-Review Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [Tree Hygiene] page, which explains my responsibilities.
• I read and followed the [relevant style guides] and ran [the auto-formatter].
• I signed the [CLA].
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I [linked to at least one issue that this PR fixes] in the description above.
• I followed [the version and CHANGELOG instructions], using [semantic versioning] and the [repository CHANGELOG style], or I have commented below to indicate which documented exception this PR falls under[^1].
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which [test exemption] this PR falls under[^1].
• All existing and new tests are passing.