Introduce template primitives for modifiers and attrs

[dfreeman]

Overview

This PR introduces template primitives for enforcing some degree of type safety with attributes and modifiers. It retires invokeModifier and introduces three new primitives:

function applyAttributes<TargetElement extends Element>(attrs: Record<string, unknown>): void;
function applySplattributes<SourceElement extends Element, TargetElement extends Element>(): void;
function applyModifier<TargetElement extends Element>(modifier: CreatesModifier<TargetElement>): void;

It also introduces ElementForTagName and ElementForComponent utility types that take a tag name or an invokable constructor respectively and give an appropriate Element subtype, or null in the case of a component with no root element.

Finally, it adds an Element field to component signatures and propagates that information to be available both for invoking them and in their template context (𝚪) in order to ensure that:

• a component being invoked accepts attributes at all
• any modifiers being applied to a component are compatible with its root element
• forwarding attributes and modifiers via ...attributes within a template is legal (i.e. the target element is equivalent to or a subtype of the component's declare Element)

Examples

Attributes

<div foo="bar"></div>
<SomeComponent foo="bar" />

applyAttributes<ElementForTagName<'div'>>({ foo: 'bar' });
applyAttributes<ElementForComponent<typeof SomeComponent>>({ foo: 'bar' });

Splattributes

<div ...attributes></div>
<SomeComponent ...attributes />

applySplattributes<typeof 𝚪.element, ElementForTagName<'div'>>;
applySplattributes<typeof 𝚪.element, ElementForComponent<typeof SomeComponent>>;

Modifiers

<div {{someModifier}}></div>
<SomeComponent {{someModifier}} />

applyModifier<ElementForTagName<'div'>>(resolve(someModifier)({}));
applyModifier<ElementForComponent<typeof SomeComponent>>(resolve(someModifier)({}));

Notes

This is a breaking change, so I'll probably aim to cut a v0.4.0 release in the near future, depending on the timing of the announcement blog post. If possible I'm also hoping to land some internal cleanup (rationalizing module layout, fixing up some type names, that sort of thing) soon, but that won't block release if we're ready to go sooner.

Closes #21.