Ferry Generator 2.0

[knaeckeKami]

Now that we have clarity around macros, it's time to start discussing the next iteration on ferry_generator.

ferry_generator has the following issues that I'd like to solve

1. problems with nesting fragments Fragments not working with interfaces #610
2. generally, slow code generation, due to how built_value puts all Serializer instances in a single Serializers object, making all serializers becoming dependent on each other - slowing down build_runner https://x.com/mraleph/status/1778517432610771380
3. code size - all these built_value classes lead to a lot of generated code
4. We don't use Dart enums, even though they would be powerful enough by now Should we not use the EnumClass for enums so that we can exhaustive match? #617

I don't think we could solve 2. and 3. without dropping built_value. 1. is a different issue, but unfortunately a fundamental flaw in the code generation logic, which would need to require a large portion of the generator to be rewritten.

I propose a new iteration of ferry_generator that does not depend on bult_value.

Goals:

• Users should still use the current code generation, ferry does not any strong assumptions on how the OperationRequest classes are generated (in fact, you could even write your own instances o use JsonOperationRequest without generating any code)
  Users will not be forced to migrate to use new versions of ferry.

• If possible, users should be able to use both versions of ferry_generator in parallel - so migration does not have to be all at once. I think this should be doable by pointing the generators in build.yaml to the right files

• Bugs with nesting fragments and interfaces are fixed

• Code generation should be significantly faster

• I want to investigate if using build_runner at all is necessary. We mainly parse graphql files, we don't need the features of build_runner a lot.
  It might be possible to do code generation optionally with a simple CLI tool.

• generating ==, hashCode and copyWith() methods should probably be optional. If you don't need these, no reason to generate them

Feedback is welcome!