Standalone content-tag implemented via conditional exports in package.json

Alternative to: https://github.com/embroider-build/content-tag/pull/41

Changes:

there are now two wasm-pack builds, one targeting noed, and one "browser" or "standalone" (as browser targets tend to be "standalone" / runnable anywhere) -- if we didn't need to support CJS, we could get away with only the standalone build
the root package.json is now the package.json that is published
- now has name, description, etc
- files entry includes the pkg directory
- has exports with conditional/subpath entries to target node/browser separately since wasm-pack generates very different output for each target (there isn't a need for this if they went for full async-only API, but :shrug: )
To test that the browser changes actually work, vite has been added to devDependencies as well as an index.html
- I tried to automate browser testing with vitest's browser mode: https://vitest.dev/guide/browser#browser-option-types -- but the browser mode does not support the same work around that vite has for https://github.com/vitejs/vite/issues/9731 -- which is setting resolve-alias for "package-name": "." (current directory) so that vite can resolve the "self's" exports. So we currently don't have automated browser testing atm. We could set up qunit instead of vitest, but we currently need to handroll a reporter to the CLI, because vite/vitest haven't given us those APIs to build custom reporters. GlimmerVM is already doing this, so it "just" needs to be extracted. This is the error:
```
[plugin:vite:import-analysis] Failed to resolve import "content-tag" from "test-browser/process.test.js". Does the file exist?
/home/nvp/Development/OpenSource/emberjs/content-tag/test-browser/process.test.js:2:48
1  |  import { __vi_inject__ as __vi_esm_0__ } from 'vitest'
2  |  import { __vi_inject__ as __vi_esm_1__ } from 'content-tag'
|                                                 ^
3  |  
4  |
```
- Due to not being able to correctly test with vitest, I added publint and @arethetypeswrong/cli to help me be more confident that the package.json was correctly configured so we don't have to rapid publishes to fix bugs with package.json config. @arethetypeswrong/cli reported some issues which are resolved now. One being this issue which is resolved by using node newer than 16 -- which... we don't declare node support at all, and node 16 is EOL'd so it seems fine to bump the CI's node.

In a real app

because my confidence in non-monorepo layouts is way lower (can't test with real projects with real module resolution),

here is a real usage:

branch with dist assets committed: https://github.com/NullVoxPopuli/content-tag/tree/non-monorepo-dist
PR to my repl here: https://github.com/NullVoxPopuli/limber/pull/1546 Results:
- Works:
```
let processor: any;
let fetchingPromise: Promise<any>;
```
export async function preprocess(input: string, name: string): Promise { if (!fetchingPromise) { fetchingPromise = import('content-tag'); }

if (!processor) { let { Preprocessor } = await fetchingPromise;
```
processor = new Preprocessor();
```
}

return processor.process(input, ${name}.js); }
```
- Does not work: 
```ts
import { Preprocessor } from 'content-tag';

const processor = new Preprocessor();

export async function preprocess(input: string, name: string): Promise<string> {
  return processor.process(input, `${name}.js`);
}
```
but this is due to: https://github.com/embroider-build/embroider/issues/1678 and this code likely would work once that 1678 issue is resolved.

embroider-build / content-tag

Standalone content-tag implemented via conditional exports in package.json #44

In a real app

@.**** commented on this pull request.