Implement optionalExpand feature

[chiroptical]

See #26

This is particularly nasty. We don't really have a choice other than passing these parameters in with each of MoatDatas records.

We really need a Reader in MoatM to handle passing around the Options. Additionally, a Reader in the pretty swift module would help as well.

• Merge Using hspec-discover we can break up the tests to avoid naming collisions during async PRs #28 and rebase this PR

[chessai]

Looks like a ton of other changes are included in this PR, making it hard to review. Maybe a rebate is in order?

[chiroptical]

Yeah, this one is based off of #28, we'll need to merge that before this one. I did this because rebasing these tests are pretty annoying each time for each feature

[chessai]

Makes sense

[chessai]

Oof, now I remember why I never fully implemented this. Lots of complexity for something that may see little use.

I'll leave it up to you if you think we should move forward with including it.

[chiroptical]

I think it is worth doing but I think it highlights some really nice refactoring we could do to clean future features like this up.

• MoatM needs Reader Options
• Each record in MoatData should carry a GenerationOptions field to contain things like Annotations, optionalExpand, etc

i.e.

data MoatData
  = MoatStruct { structExpandOptional :: Bool
               , structAnnotations :: Annotations
               , structData... :: Data...
               }
  | ...

becomes

data MoatData
  = MoatStruct { structGenerationOptions :: GenerationOptions
               , structData... :: Data...
               }
  | ...

I think this would allows us to pull out the TH into a separate function and clean the code up quite a bit.

[chiroptical]

• With a common type for all fields, we can also add a Reader GenerativeOptions to the pretty code too

I think these three things would make new generative features quite a bit easier.

The other option was allowing one to change the generative options at generation time, however I prefer the former for two reasons. I experimented with MoatType.Optional carrying this feature but the TH becomes confusing to me quickly. It also means we need to touch more TH each time we add a generative feature (and not easy TH). Second, the decision is made at compile time and the generative options can be chosen for each of your types. e.g. Maybe you only want to optionalExpand for one specific type for some reason.

[chiroptical]

I think I'll leave this one open as a reminder to do this refactoring