feat: Serialize FCS

[dickermoshe]

In preparation for a future version of FCS where schemas can be shared, it would be nice if an entire schema could be serialized.
I've done the work on this using dart_mappable, however there are a couple of classes which can't be serialized.

Some can't be serialized because the internal data is private:

• ColorFilter
• TextDecoration
• MaskFilter

Others are abstract:

• ThemeExtension
• Shader
• ImageFilter
• InteractiveInkFeatureFactory
• EdgeInsetsDirectional

And others are hopelessly complex:

• MaterialStateProperty
• PageTransitionsTheme

I'm hoping that there is a solution for private data.

Abstract classes which aren't sealed can't reliably be parsed, however, we can try to parse the ones that Flutter provides (EdgeInsetsDirectional -> EdgeInsets | EdgeInsetsDirectional)

The ones which are too complex will be ignored, we can explore ways for users to write PageTransitionsTheme & MaterialStateProperty in a way that can be serialized.

I've forked this here:
https://github.com/dickermoshe/flex_color_scheme

[dickermoshe]

The next step after this is to serialize the deltas that a ThemeData.copyWith(...) does.
This will allow us to serialize all that we need.

In other words, we would love if the entire theme was customizable.
FleColorScheme makes it easy to get most of the way there. But if we want people to have this much control, we will have to serialize the entire ThemeData class.

This presents somewhat of a quandry, which do we serialize? ThemeData, with all of it's 1000 properties, or FCS, which has limited customization.

The solution is to FlexColorScheme, and a special class that takes a FlexColorScheme and applies the copyWiths to it.

const theme = FlexColorScheme(...);

class MyTheme extends ThemeCopyWiths {
  final FlexColorScheme scheme;
  FlexColorSchemeCustomizer({
    this.cardColor = Value.absent;
  });
  
  @override
  Value<Color> cardColor;
}

The ThemeCopyWiths and FlexColorScheme can be serialized, so this would allow for almost complete customization.. Referencing the original values within a copyWith would be much more complex (originalCardColor.lighten()) and would need to be explored much more.

This would allow us to crate a Playground with seemingly unlimited customization.

I'm excited for the day when entire designs could be a .json file, which could generate an entire theme.
We could also explore for people to make variants of different designs :

return BigButtonVariant(
  child: ElevatedButton(
    child Text("Big Button")
  )
);

I'm prob just rambling at this point. There are still lots of parts to think about.