Makes setup of transformer based serialization more simple.

The goal of this PR is to simplify the setup of transformer based serialization while keeping it flexible and also make the Editor happy (no more importing of not-yet generated files). This includes the following changes:
 - Generate one file containing all generated serialization rules
 - Automatically replace the ...serialization.dart import with the generated Serialization rules file. It overrides the constructors so that all generated rules are automatically added.
 - Generate rules for Classes with the @Serializable() annotation.
 - Fixed bug where "part of" files where not imported properly (because we need to import the main library file).
 - Allow to process classes of files that are in imported packages (couldn't do that with the $include: ["lib/stuff.dart", "lib/more_stuff.dart" ...] in the old transformer).

With these changes developers can just do:

    import 'package:serialization/serialization.dart';
    ...
    var serialization = new Serialization();
    
    Person person = new Person();
    ...
    var personJson = serialization.write(person);

And the pubspec.yaml declaration looks like this:

    transformers:
    - serialization :
      useAnnotation: true
      files:
      - bin/stuff.dart
      - lib/more_stuff.dart
      - package:package_name/3rd_party_stuff.dart #for imported packages
There are a few reasons I did this:
 - The editors show an error when using `ThingWithDateSerializationRule` because it's not generated yet.
 - To avoid collision of rules names I need to add a prefix to the generated rule class name (currently using a counter so the current name is: `_0ThingWithDateSerializationRule`). That's in the case multiple class named `DateSerializationRule` from different files are imported.
 - It feels that by using `ThingWithDateSerializationRule` the user is relying too much on implementation details (matching naming) whereas with the above he is now relying on defined interface (CustomRule and Serialization.automaticRules[]) available before transformer run...

Thing is I would like to be able to keep this and have stable naming but now that all rules are in the same file there is a risk of name collision (actually happening in the tests). Not sure how to work around that... Or maybe we can use another prefix for the generated rule class name like: `$filename_ThingWithDateSerializationRule` ?