[BUG][Dart] Should use final for variables

Description

When generating Dart code, I get nullable values and this comment:

  ///
  /// Please note: This property should have been non-nullable! Since the specification file
  /// does not include a default value (using the "default:" property), however, the generated
  /// source code must fall back to having a nullable type.
  /// Consider adding a "default:" property in the specification file to hide this note.
  ///

I don't understand why a default value is required for a value that should always be specified?

openapi-generator version

master

Steps to reproduce

java -jar modules/openapi-generator-cli/target/openapi-generator-cli.jar generate -i http://localhost:8080/openapi.yaml --additional-properties=serializationLibrary=json_serializable -g dart -o output

Suggest a fix

Ideally, the variables should be defined as final and could look something like this:

@JsonSerializable()
class Auth {
  final String userId;
  final String token;

  Auth(this.userId, this.token);

  static Auth fromJson(Map<String, dynamic> json) => _$AuthFromJson(json);
  Map<String, dynamic> toJson() => _$AuthToJson(this);
}

Instead, the generated code looks more like this:

class Auth {
  /// Returns a new [Auth] instance.
  Auth({
    this.userId,
    this.token,
  });

  ///
  /// Please note: This property should have been non-nullable! Since the specification file
  /// does not include a default value (using the "default:" property), however, the generated
  /// source code must fall back to having a nullable type.
  /// Consider adding a "default:" property in the specification file to hide this note.
  ///
  String? userId;

  ///
  /// Please note: This property should have been non-nullable! Since the specification file
  /// does not include a default value (using the "default:" property), however, the generated
  /// source code must fall back to having a nullable type.
  /// Consider adding a "default:" property in the specification file to hide this note.
  ///
  String? token;
  
  ...
}

Start with the documented openapi-generator-cli command and the generated Dart Auth class shown in the issue. Compare how required properties without defaults are represented and determine the generator entry point and tests covering Dart serialization. Done means the intended required-property behavior is generated consistently without the nullable warning.