Refactor everything in SDT for compile-time code generation

[raquo]

See #87 for rationale and discussion.

This PR is taking the second approach – consuming libraries will call an SDT method at compile time to generate the code of all the traits that previously lived in SDT (HtmlAttrs, Props, Styles, etc.) They can also write their own code generators.

In the initial commit, I made parser to parse existing SDT traits and generate the code of the new SDT. The generated code is in src/main/scala/com/raquo/domtypes/shared/defs, and the new type definitions are in src/main/scala/com/raquo/domtypes/shared/common. Basically everything else in this project will be nuked.

Lots of stuff is still WIP, but if you're interested you might want to look in the two directories mentioned above.

Next step for me is writing the code generators that will take this new SDT data and generate the source code of the traits that you would want to actually use in third party libraries.

SDT also used to contain a few small helpers like Codec-s, SvgNamespaces, and VendorPrefixes. I'm not yet sure if I will keep those in SDT, or if each library will just need to copy-paste a few files. These particular helpers don't really ever change.

[raquo]

I've implemented most generators that will generate Laminar / Outwatch / etc. source code from the new SDT data. For some examples:

1. SDT source data now looks like this: PropDefs and ReflectedAttrDefs

2. In your library, you call the relevant generator at compile time to produce a trait like this: Props (this combines props and reflected-attrs-implemented-as-props in one trait)

3. In your library, you provide a few of your own types like Attr, Codec, etc.

4. When all is said and done, you end up with a file structure like this example in your own project. It should be very similar to what you already have.

The code generation is configurable / extendable, but not infinitely so. At some point it might be easier to write your own non-generic generator, but I expect all reasonable frontend use cases to be covered by the canonical generator hosted in SDT. If some required customization is missing, it can be added later.

The traits in thirdparty/defs are currently generated by GeneratorSpec as an example.

I still need to finish the parsing and generation of CSS styles, and work on edge cases like composite keys, aliases, etc.

[raquo]

FYI I'm also dropping Scala 2.11 support, seems like a waste of cpu cycles nowadays.

[raquo]

Dropped built-in support for TypedTargetEvent. I think it only complicated type signatures, and for little gain, since the best type we could infer would be dom.html.Element (not e.g. dom.html.Input, which would let you access .value). It can't be made both type safe and more useful even if it's complicated even further, so down the drain it goes.

If you really want to support TypedTargetEvent in your own library, the new generators should be flexible enough to allow that. For myself, I plan to ditch TypedTargetEvent in Laminar in favor of the type-safe inContext { thisNode => and unsafe mapToTargetAs[elementType].

--

Also, temporarily dropped support for the tupled convenience method on the display style prop: display.tupled("inline", "flex"). It was half-baked, and I will eventually develop a more useful and more generic version, but not right now.