create metrics collection/consent library for our use

[SgtPooki]

This library should contain the code from ipfs/public-gateway-checker#309, in a way that can be consumed by the packages listed at #105

We should host this library at https://github.com/ipfs-shipyard/ignite-metrics and publish to npm as @ipfs-shipyard/ignite-metrics

A few requirements for this library:

Functional requirements

1. Code is ESM.
2. Export ESM.
3. Can be consumed by CJS react libraries
4. can be consumed by ESM react libraries
5. can be consumed by CJS non-react libraries
6. can be consumed by ESM non-react libraries
7. For non-react libraries, the https://github.com/ipfs-shipyard/ignite-metrics/blob/ec17cc85748319d1dfe42003feea3a76eba209cf/src/CountlyMetrics.ts file will need to be enough for consumers to consume as they will not be able to consume the react components.

Inputs

1. countly API key and url
2. consent warning text/component
3. consent acceptance text/component

Exports

1. Warning component: https://github.com/ipfs/public-gateway-checker/blob/c727202d5a98b9e191a9d979fdb4e40e8d23cf43/src/index.html#L16-L25
2. consent component: https://github.com/ipfs/public-gateway-checker/blob/master/src/index.html#L26-L35
3. consent toggle component: https://github.com/ipfs/public-gateway-checker/blob/c727202d5a98b9e191a9d979fdb4e40e8d23cf43/src/index.html#L69-L84
4. Countly instance/global (this could be something else in the future)

[whizzzkid]

Just documenting my thoughts on the future:

• publishing pure ESM for both web and node
• warning/accept hooks, independent of how those are being consumed.
• initialization checks based on configured values for tracking enabled or disabled.
• An ergonomic api by leveraging a plugin system to add additional metrics faster, maybe even have something like:

   const metrics = new IgniteMetrics();
   metrics.init(['PAGEVIEWS', 'SESSIONS', 'CLICK_EVENTS'...]

• Then we can build react wrappers around this to make it easier to integrate.