Dart Generator: `http` package needs to be Aliased

Hi all, thanks again for all your hard work :) Another quick bug report: The Dart generator does not alias the http package import, and therefore any types it defines can conflict with types you define in your OpenAPI Spec.

Example: Our OpenAPI spec contains the following component:

Response:
      type: object
      properties:
        id:
          type: string
        receivedAt:
          type: string
          format: date
        body:
          type: string
        seenAt:
          type: string
          format: date
        type:
          type: string
          enum:
            - accepted
            - rejected
            - offer
            - other

The problem? When the Dart client is generated, it imports the http package but does NOT alias the import. The generator creates a Response class itself! Therefore, there is a naming conflict between these two.

Suggested solution:

The generator and generated code should alias the http import, and use http.Response everywhere instead of regular old Response. This naming conflict could happen with anything the http package exports, which also includes very generic names like Client which are likely to be used in Specs.

Start by locating the Dart generator code that emits the http package import and references to Response or Client. Check the generated Dart output against a spec defining a Response component; done means the import is aliased and generated uses of the package types are qualified without conflicting with generated model names.