This PR makes a change to the build process: Previously, transpiled JS, declaration files and source maps were written into dist. To align Replay with the build process in the SDK monorepo, this PR makes the following changes:

• Change build output to build/npm (see explanation below)
• Change build:npm command to execute a prepack script
• Temporarily introduce the ./scripts/tmp-prepack.ts script which copies files like README.md, LICENSE and package.json into build/npm. This is a simplified version of the monorepo's prepack script. While doing so, the script makes changes to package.json to align the entry points.
  • This file will be removed once we migrated as we can then use the monorepo's prepack script.
• Remove the files entry in package.json for consistency with the monorepo (we just rely on .npmignores)
• Adjust occurrances of dist folder, replacing or adding build as appropriate

As of this PR, the build directory will have the following structure:

<replay-root>/
├─ build/
│  ├─ npm/ <-- everything in this directory goes into the NPM tarball
│  │  ├─ types/
│  │  │  ├─ *.d.ts files (+maps)
│  │  ├─ index(.es)?.js file + map
│  │  ├─ package.json
│  │  ├─ LICENSE
│  |  ├─ README.md
├─ ...

More context on the JS SDK's build directory structure:

While this is arguably not the simplest setup, the structure below serves two purposes:

1. Have one directory per SDK into which all build and artifact (tarball, CDN bundle) related files go
2. Be able to make modifications to the files we ship vs. the ones we keep in the repo.
   For example, we remove certain properties in the shipped package.json, which our users don't need

Once we finished the migration of Replay, the build directory structure will be identical to the JS SDK structure of SDK packages with bundles:

<replay-root>/
├─ build/
│  ├─ bundles/ <-- that's where the CDN bundles will live
│  ├─ npm/ <-- everything in this directory goes into the NPM tarball
│  │  ├─ types/
│  │  │  ├─ *.d.ts files (+maps)
│  │  ├─ esm/
│  │  │  ├─ ESM JS files (+maps)
│  │  ├─ cjs/
│  │  │  ├─ *CJS files (+maps)
│  │  ├─ package.json
│  │  ├─ LICENSE
│  |  ├─ README.md
├─ ...

Note that as soon as we change the entry point paths in package.json (main, modules, types), we're technically introducing a breaking change. It is however a very edge-case-y scenario in which users import modules from an explicit path rather than from the top-level package:

// this import would break after moving the index file to esm/index.es.js
import {} from '@sentry/replay/index.es';

// this import would still work as expected
import {} from '@sentry/replay';

I would argue that introducing this breaking change is fine as long as we're in this 0.x/alpha state but I'm happy to hear other opinions on this.

As of this PR nothing breaking is happening yet.