feat: Publish dual CJS and ESM builds

[mykola-mokhnach]

Summary

• Publish both a CommonJS and an ESM build from the same TypeScript source (build/cjs and build/esm, each with its own package.json marker), so existing require('asyncbox') consumers keep working unchanged while new consumers can import it natively. Wired up via a conditional exports map (plus main/module/types fallbacks) and a postbuild script that stamps each output directory with its own {"type": ...}.
• Adopt the lint/format/release tooling; swap ESLint + Prettier for oxlint/oxfmt via @appium/oxc-config, replace the hand-rolled .releaserc with @appium/semantic-release-config, and add .editorconfig.
• Add cjs-interop.spec.cjs test that require()s the CJS build directly, so a future change that breaks CJS consumption (e.g. an ESM-only dependency bump) fails CI instead of only being caught by the ESM test suite.

Details

• p-limit (a runtime dependency) is ESM-only. The CJS build's require('p-limit') works because it relies on Node's native require(esm) support, available on the versions already required by engines (^20.19.0 || ^22.12.0 || >=24.0.0). tsconfig.cjs.json uses moduleResolution: "Bundler" (paired with module: "CommonJS") so tsc can resolve p-limit's types, which only exist under its exports field with no top-level main/types.
• tsconfig.json is now the shared base (no outDir) that tsconfig.esm.json (outDir: build/esm) and tsconfig.cjs.json (outDir: build/cjs) extend; it's also what editors/tsserver and oxlint's type-aware mode pick up by default.
• Dropped the explicit typescript devDependency — @appium/tsconfig already pins and ships it as a dependency, so restating it here just risked drift.
• Ran oxfmt over the existing source, which reordered imports (node builtins → third-party → relative, each group blank-line separated) to match the shared config's conventions — same reformatting appium-xcode#190 applied.

[eglitise]

This mixes up several unrelated changes, so I would prefer if the lint/format changes were moved to a separate PR.

[mykola-mokhnach]

This mixes up several unrelated changes, so I would prefer if the lint/format changes were moved to a separate PR.

This is a small repo and the amount of changes is small. I expect splitting this PR would require more tokens than its creation

[eglitise]

My point is that it's more complicated to review as a result. I'm not confident enough in CJS/ESM specifics to review them, but that's not the case for the lint/formatting changes.

(also I don't think we should be optimising for token use if that results in PRs that combine multiple different changes, but perhaps that's just me)

[mykola-mokhnach]

Closed in favour of #85