Convert to using exports in package.json

[cmdcolin]

The "module" field is not standard, but helps bundlers understand the 'esm' intent which improves tree shaking, etc.

This changes to using the more standard package.json "exports"

Some exports docs here https://nodejs.org/api/packages.html#package-entry-points

This is still 'dual cjs/esm' but to try to enable a more "pure esm" concept compared to just "module" which still uses node.js module resolution, I added a new typescript option called 'path rewriting'. This makes us import from .ts extensions in the src directory, which changes to imports with the .js extension after building with tsc https://devblogs.microsoft.com/typescript/announcing-typescript-5-7/

[cmdcolin]

(this package was a small low effort attempt since this package is small and self contained. it could be propagated more largely through other data parsers and even the jbrowse codebase if successful though)

motivated somewhat by this issue where we have trouble with vite at dev time, potentially due to our "module" field not being recognized by esbuild (vite dev time) and so the commonjs builds are used which is sensitive to the order of imports causing weird crashes...

mui/material-ui#44180

[cmdcolin]

this PR may be insufficient

to properly do it, it will need to

a) add type:"module" to package.json
b) make the files in the dist folder use the .cjs extension to force it to use commonjs

see "build with typescript" section here https://evertpot.com/universal-commonjs-esm-typescript-packages/

it also discusses an alternative to .cjs extension which is adding a one line package.json that says type:"module" in the esm folder and type:"commonjs" in the cjs folder, but i am a little wary of the folder specific package.json's

[cmdcolin]

settling on making the package.json with {type:'commonjs'} in the dist folder in this PR now

i mention above being wary of it but since the dist folder is nodejs specific, and nodejs is attuned to this behavior, it seems ok