Renames $.hydrateElement() to $.hydrate().

This function serves the purpose of hydrating a given element and is the better fit for that name. The original implementation of `$.hydrate()` has been renamed to `$.read()`.

This means we now have three functions which serve the purpose of "get an element from shadow DOM and do something useful with it". To break down the differences:
* `$.query()` - Queries the shadow DOM for the element and returns it unmodified and with no side effects. Not intended for custom elements because they are possibly not hydrated yet.
* `$.read()` - Queries the shadow DOM for the element and converts it to a more useful representation with no side effects (parses `textContent` to a `Number`, parses JSON from an attribute, etc.). Not intended for custom elements because they are possibly not hydrated yet.
* `$.hydrate()` - Queries the shadow DOM for the custom element and triggers hydration with the provided props, returning the hydrated element. This is specifically for custom elements and side-effectfully triggers hydration.

README.md

@@ -121,9 +121,8 @@ Some notable trade-offs between the two authoring formats:
     JS decorator proposal.
 *   Returning object in functional approach feels like it's hacking in the class
     approach in the middle of the functional approach.
-*   When to use `$.hydrateElement()`, `$.read()`, and `$.query()` is not clear. Class
-    approach uses `@hydrate()` as a declarative decorator while `this.query()` is
-    imperative.
+*   When to use `$.hydrate()`, `$.read()`, and `$.query()` is not clear. Class approach
+    uses `@hydrate()` as a declarative decorator while `this.query()` is imperative.
 *   `update()` isn't necessary in the functional design, can just use effects.
 *   Functional approach requires returning the custom element definition and "moving"
     its properties over, which feels very hacky.

src/examples/nested-deferred-counter.ts

@@ -25,7 +25,7 @@ declare global {
 // Nothing unique about this component.
 // Automatically supports deferring hydration with no effort!
 const DeferredOuterCounter = component('deferred-outer-counter', ($) => {
-  const innerCounter = $.hydrateElement('deferred-inner-counter', DeferredInnerCounter);
+  const innerCounter = $.hydrate('deferred-inner-counter', DeferredInnerCounter);
 
   // Child elements are hydrated first, so this is already loaded and works!
   // Note that HydroActive cannot force the custom element classes to be loaded for all its

src/examples/orchestrated-counter.ts

@@ -42,10 +42,10 @@ const OrchestratedParent = component('orchestrated-parent', ($) => {
   const user = getUser($.read(':host', Number, attr('user-id')));
 
   // Hydrate `orchestrated-initial-count` *first* and get the initial count from it.
-  const { count } = $.hydrateElement('orchestrated-initial-count', OrchestratedInitialCount, { user });
+  const { count } = $.hydrate('orchestrated-initial-count', OrchestratedInitialCount, { user });
 
   // Hydrate `orchestrated-counter` *second`, using the initial count we just hydrated.
-  $.hydrateElement('orchestrated-counter', OrchestratedCounter, { count });
+  $.hydrate('orchestrated-counter', OrchestratedCounter, { count });
 });
 
 declare global {

src/functional.ts

@@ -396,9 +396,8 @@ class Component<
     return value;
   }
 
-  // TODO: Rename to `$.hydrate()`.
   // TODO: Consider adding `$.hydrateChildren()`.
-  public hydrateElement<Clazz extends Class<Element>>(
+  public hydrate<Clazz extends Class<Element>>(
     selector: string,
     clazz: Clazz,
     // `props` is optional if the class does not have any required props.