Typespec schema changes

[aothms]

Follow-up of #7.

For discussion.

Questions:

• (as discussed) Is the aliased union of component types enough or do we need to add a type discriminator? I can imagine at least validation would be nicer with a discriminator tag, because the validator then knows what it should be as opposed to trying all.
• How to deal with extensibility? Could we do an experiment where somebody extends this schema with some vendor specific component type? How does he break open the union to add his own types? Is inheritance easier in this sense or is typespec just not built with extensibility in mind? Potentially relates to the discriminator question above. If typespec is not built for this I'm also fine with doing a two-step validation 1 schema for the payload envelope and a separate more flat schema with discriminated (?) component types that can be more easily concatenated with vendor component schemas. Or a little bit of code to add our own discriminator based on the key.
• I added a Prim supertype for the Over/Def/Class (in the PR to your branch). Also fine with it being a union instead.
• We should probably get the disclaimer out and think a little bit about a proper header for the data.