Possible re-think/design of the API response content types

[MattDrivenDev]

Need to think carefully (sooner rather than later) about the response content (record) types. For example:

• Repository
• User
• Owner
• etc etc

I'd like to change the API output/content types to something more considered/structured - that helps give the client application code more semantics about the data as part of the types:
See here for more details on examples

There are two options as I see it:

1. Use the FSharp.Data Json Type provider... but only internally for reading of the data (meaning we can drop the massive annoying record types).
2. Lock/hide the massive annoying record types away as internal types.

In both cases, there will be some functions to convert over from the deserialized types - into the proper API content types which make better use of the F# type system.

[MattDrivenDev]

Further thinking to this is that there will be an option as part of calling the GitHub.Whatever - an option to say pass me back the unwrapped types and the wrapped types (or perhaps use the state object).

There will be clear reasons and benefits for using both: Correctness v.s. Performance

This also means that development can basically just go full steam ahead for this version, with unwrapped types - just to get the API up-and-running, but also means when we add support for wrapped types it is still backwards compatible for anyone already using the API.

Plan :)

I think it is worth a proof-of-concept on a branch somewhere though.