Related to [#62][] (see [3.2. Template Parts and Custom Template Process Callback][])
Follow-up to [#65][]

While the changes made in [#65][] improved support for `Element` parts,
the expansion from `string` to `Element | string` was not broadened
enough. While all `Element` instances are DOM Nodes, not all DOM Nodes
are `Element` instances.

For example, this change enables support for [DocumentFragment][]
instances (generated from classes like [Range][] or properties like
[HTMLTemplateElement.content][]), where prior support resulted in
templating the `[object DocumentFragment]` text string instead of the
fragment's `Node` instances.

[#62]: #62
[3.2. Template Parts and Custom Template Process Callback]: https://github.com/WICG/webcomponents/blob/159b1600bab02fe9cd794825440a98537d53b389/proposals/Template-Instantiation.md#32-template-parts-and-custom-template-process-callback
[#65]: #65
[DocumentFragment]: https://developer.mozilla.org/en-US/docs/Web/API/DocumentFragment
[HTMLTemplateElement.content]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLTemplateElement/content

Accept `Node` values as Template Parts

Replace `ChildNode` with `Node` in `NodeTemplatePart.replace(...nodes)`
signature.

According to the [3.2. Template Parts and Custom Template Process
Callback][] section of the specification, the `NodeTemplatePart`
interface declares `replace(...nodes: Array<string | Node>)`:

```typescript
interface NodeTemplatePart : TemplatePart {
  readonly attribute ContainerNode parentNode;
  readonly attribute Node? previousSibling;
  readonly attribute Node? nextSibling;
  [NewObject] readonly NodeList replacementNodes;
  void replace((Node or DOMString)... nodes);
  void replaceHTML(DOMString html);
}
```

This commit changes the type signature and adds coverage for replacing a
`NodeTemplatePart` with a `DocumentFragment` instance.

[3.2. Template Parts and Custom Template Process Callback]: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md#32-template-parts-and-custom-template-process-callback

Change `NodeTemplatePart.replace` type signature

The [3.3. Conditionals and Loops using Nested Templates][] section of
the specification mentions special treatment of `<template>` elements
with `[directive]` and `[expression]` attributes within `<template>`
elements. They're to be treated as parts of their own, represented by an
`InnerTemplatePart` interface:

```ts
 InnerTemplatePart : NodeTemplatePart {
    HTMLTemplateElement template;
    attribute DOMString directive;
}
```

This commit introduces that class, along with special treatment whenever
collecting parts from an `HTMLTemplateElement` that also has a
`[directive]` attribute.

To demonstrate their utility, this commit includes a test case that
exercises a naive implementation of an `if` conditional. As a caveat,
it's worth mentioning that the specification proposal explicitly
mentions the nuance surrounding looping and conditional rendering:

> this approach involves the template process callback cloning template
> parts along with other nodes, or let author scripts manually specify to
> which element each template part belongs. This quickly becomes an
> entangled mess because now we could have multiple template parts that
> refer to a single DOM location or an attribute, and we have to start
> dealing with multiple template parts trying to override one another even
> though there is no good use case for such a behavior.
>
> We like the idea of supporting very basic control flow such as `if` and
> `foreach` in the default template process callback but we don't think it's
> a show stopper if the default template process callback didn't support
> them in the initial cut.

This commit does not aim to introduce a canonical implementation for
conditionals or looping, but it should enable a change like that in the
future.

[3.3. Conditionals and Loops using Nested Templates]: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md#33-conditionals-and-loops-using-nested-templates

Implement `InnerTemplatePart` class

Existing test coverage lacked tests that exercised _both_
the default `processPropertyIdentity` strategy alongside the optional
`propertyIdentityOrBooleanAttribute` strategy.

This commit doesn't contain any implementation changes, but broadens
test coverage instead.

Add an entry to the `src/index.ts` to export the new
`InnerTemplatePart`.

Since consumers are most likely to import `TemplateInstance`, change the
`test/template-instance.ts` test file to import properties from the
module in a way that more closely resembles the end-user consumer
experience.

Export `InnerTemplatePart`

Add test coverage for both built-in processor strategies