Infra: Provide solution for duplicate component registration about pharos

[Niznikr]

Lit itself also provides a separate mixin that integrates with the CustomElementRegistry polyfill. Because shadow roots are used as registration scopes in the proposal, we need to perhaps provide a helper for consumers to scope their version of Pharos. This helper would attach a shadow root to a given element and then define Pharos components on it for folks to use and scope their app/page.

[Niznikr]

There are two possible solutions for us:

1. We create a <pharos-registry> component that utilizes the @lit-labs/scoped-registry-mixin to scope our components within its shadow root. Consumers could then use the component as such:

<template id="my-template">
  <h1>My page template</h1>
  <pharos-button>hi</pharos-button>
</template>
<pharos-registry></pharos-registry>

And in their JS entry file:

import { PharosRegistry } from '@ithaka/pharos/lib/components/core/pharos-registry';
customElements.define('pharos-registry', PharosRegistry);

document.querySelector('pharos-registry').shadowRoot.append(document.querySelector('#my-template').content);

This would remove the need for consumers to import individual components but at the cost of needing for their template to exist in the shadow DOM which would require changes to references of document.querySelector and integration tests.

2. Only use @lit-labs/scoped-registry-mixin within our own components that import other Pharos components and remove the @customElement decorator to stop self-registering. Instead we only export the component class and let consumers define a unique tag for their app:

import { PharosButton } from '@ithaka/pharos/lib/components/button/pharos-button';
customElements.define('pharos-button-homepage', PharosButton);

This would place responsibility on the consumer to define a unique tag. Any integration test helpers would need to allow configuration for custom tags because of this new flexibility.