Reconsider where types come from

[Swatinem]

Currently, intl-codegen just collects all the used variables inside the translations to generate some type hints.

The goal here is:

• we want developers to pass the correct variables to <Localized />
• we also want translators to make correct use of the available variables inside the translations
• we want to have richer and better types that ensures correct usage on both sides
  • make sure that things like nullable types are matched on via select
  • number types should be used with number
  • date types should be used with date / time
  • a much improved compound currency type (Add nice currency formatting support #14)
  • remove the possibility to pass ReactNode (Experiment with DOM Overlays #15)

The way our usage of intl-codegen has changes shows me that it might be a good idea to define some kind of schema that defines:

• obviously the message ids that exist
• the names and types of all the variables

[Swatinem]

I implemented something that is similar to this proposal from fluent: projectfluent/fluent#140
typing for messageformat based definitions is done manually.
currently has support for string, number, datetime, monetary and element.
element is a special case, which accepts React.ReactNode as param, and switches any localization string that has a element param to return Array<React.ReactNode> instead of string.