Support helper-based type narrowing

[dfreeman]

The level of complexity in helper signatures currently prohibits them from acting as type guards, which is especially problematic since templates don't have a native notion of equality, so you can't do the equivalent of ad-hoc if (obj.discriminatorField === 'discriminant-value') checks.

This PR makes a few changes that, together, enable helpers to narrow the types of their arguments.

// Today, a helper signature looks something like this:
declare const isNumber: (named: NoNamedArgs, value: unknown) => ReturnsValue<boolean>;

// And invoking it in a conditional would translate to code like this:
if (invokeInline(resolve(isNumber)({}, maybeANumber))) {
  // ...unfortunately, we know nothing about `maybeANumber` here
}

There are two things that prevent isNumber from narrowing the type of maybeANumber. First, the ReturnsValue makes it impossible to represent a value is number at all, as such is clauses are restricted syntactically so that they can only be the direct return type of a function. Second, even with that solved, the wrapping invokeInline function would still degrade a type guard to a regular boolean-returning function.

The change in this PR eliminates the ReturnsValue macro, so that helpers are represented essentially as their raw function types. Pulling on the thread of that change, signatures as a whole can become much simpler, with the CreatesModifier type becoming a plain marker object. The Invokable<T> wrapper and AnySignature type both go away entirely, as they'd already been weakened nearly to the point of doing nothing and with this change they no longer deliver any value at all.

Secondly, it eliminates invokeInline as a peer of invokeModifier and invokeBlock. Instead, invokeEmit now exists, but is only applied to values that will be emitted into the DOM either directly as content or into an attribute or concatenated string (which provides a bit of type safety against [object Object] showing up on screen). In cases where the return value of a helper is actually treated as data, such as a component @arg or a helper parameter, no invoke helper is required at all and the value is passed directly.

Together, these changes make the snippet above into something more like:

declare const isNumber: (named: NoNamedArgs, value: unknown) => value is number;

if (resolve(isNumber)({}, maybeANumber)) {
  // here, we know that `maybeANumber` is in fact a number
}

[chriskrycho]

Ooooh, I like this change a lot. 👏