gracefully and accurately handle "empty" entry points and dependency files that don't `export` a custom element

[thescientist13]

Summary

As observed / reported in https://github.com/ProjectEvergreen/greenwood/issues/1185, WCC checks every file it process as part of initializeCustomElement looking for custom element definitions, naturally. However, in the Greenwood case, all code / chunks related to rendering out SSR HTML might not always be cleanly provided as only having an export default Foo extends HTMLElement.

This leads to cases where WCC will log out to the console and "silently" fail by returning an empty HTMLElement

if (element) {
  // ...

  return elementInstance;
} else {
  console.debug('No custom element class found for this file');
  return new HTMLElement();
}

We should not be so noisy in reporting and instead only rely on our warning for missing custom element definitions.

Details

Seems related to #85 but instead of just successfully failing, and to accomplish a middle ground here and not completely lose out on error miessaging / feedback to users, renderToString makes the assumption the entry point is a custom element, relying on the default HTMLElement being returned by initializeCustomElement

async function renderToString(elementURL, wrappingEntryTag = true, props = {}) {
  // ...
  const elementInstance = await initializeCustomElement(elementURL, undefined, undefined, definitions, isEntry, props);

  const elementHtml = elementInstance.shadowRoot
    ? elementInstance.getInnerHTML({ includeShadowRoots: true })
    : elementInstance.innerHTML;

  //....
}

We should probably at least add a check here and just return undefined and then show the warning.