Use of dart augmentation `augment` capabilities to facilitate future `@Codable()` annotation

[timmaffett]

I created PR #9 in order to prototype possible code that a future @Codable() annotation might trigger to be built via a build_runner builder.

In the changed model examples the @Codable() annotations are indicated where they might occur (within comments) and the corresponding part files are named *.codable.dart . These part files would presumably be produced by the codable_builder at some point.

The naming scheme for the part files follows the pattern established by dart_mappable.

I wanted to prototype these part files (using the new augment keyword) now so that we can discover any bugs and limitations within the current augmentation implementation as soon as possible. I did discover several, but I am hopeful that they will quickly be resolved by the dart language team (especially now that the dart macros have been discontinued). I have filed issues for two of the discovered problems (dart-lang/sdk#60040 and dart-lang/sdk#60039)

I would be interested in spurring a conversation about what a potential @Codable() annotation might look like.

Within the examples in the PR I imagined simple @Codable() annotations that would trigger automatic creation of the data class constructor (and other codable required member variables and methods)
I also imagined optional arguments which could be used to trigger the creation of the equatable == operator and hashCode methods, as well as the toString() method.
@Codable(equatable:true,toString:true)

These argument names/syntax are completely arbitrary and provided only as a placeholder for what might be desirable/possible.

I would imagine that there would also be @Encodable() and @Decodable() versions that would only trigger the corresponding encodable or decodable code generation (and @Codable() triggering both)

What other annotations would be desirable?

[timmaffett]

I'll start with some ruminations about possible ways to facilitate versioning in data classes - lol
(and presumably versioning pertains primarily to binary/non-human readable serializations)

I imagine a versioning capability could be implemented/triggered by something like the addition of a version argument to the @Codable() annotation something like this:

@Codable(version:2)
class myVersionedData {
   @Version(1)
   final String name;
   final int age;
   @Version(2)
   final String address;
   final String city;
   @Version(3)
   final String countryCode;
}

The 'version:2' in the Codable annotation could trigger the addition of a leading 'version' integer within the data class:

augment class myVersionedData {
   final int version=2;
}

The corresponding encode and decode routines would write/read this version integer as the first attribute.
The @Version() annotations intermixed within the data class attributes could be used to delineate where new attributes where added as versions evolved. The encode method would presumable always output the latest (complete) version, but the decode method could use the initial read version integer to know what to expect as the deserialization progressed.
This is of course the simplest model of versioning, where only new attributes are added to the end of the data class. but annotations could expand what would be possible (such as deleting or reordering of attributes).

``