Fix CommonJS import compatibility

[aduth]

🛠 Summary of changes

Fixes another regression of #395, where downstream projects can resolve the CommonJS built output, but would treat its code as ES Modules, since the project's top-level package.json includes "type": "module". It's unclear why this wouldn't have been an issue prior to #395.

Example failure: 18F/identity-idp#9992

Error:

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for /Code/identity-idp/app/javascript/packages/clipboard-button/clipboard-button-element.spec.ts

I'm not 100% about the solution here since typically a package would only contain a single, root-level package.json. However, I've tested to confirm that it works, and have seen the idea referenced in a few places:

• https://2ality.com/2019/10/hybrid-npm-packages.html#option-3%3A-bare-import-esm%2C-deep-import-commonjs-with-backward-compatibility
• Improve documentation on Dual Module Packages nodejs/node#34515 (comment)

The alternatives could be to use either Babel CLI's (prior to 9.0.0) --out-file-extension .cjs or ESBuild's (after 9.0.0) --out-extension:.js=.cjs to control the file extension output for CommonJS. However, there's not an easy solution to change the source code's path references based on the built output type, aside from using a third-party plugin like babel-plugin-replace-import-extension.

📜 Testing Plan

This is easiest to verify via the pull request mentioned above: 18F/identity-idp#9992

1. cd identity-idp
2. git checkout dependabot/npm_and_yarn/18f/identity-design-system-8.1.1
3. yarn install
4. yarn mocha app/javascript/packages/clipboard-button/clipboard-button-element.spec.ts
5. Observe the error mentioned above
6. Apply fix manually: echo '{"type":"commonjs"}' > node_modules/@18f/identity-design-system/build/cjs/package.json
7. Re-run yarn mocha app/javascript/packages/clipboard-button/clipboard-button-element.spec.ts
8. Observe test passes successfully

[aduth]

Visual regression failure is being addressed separately at #402