chore(publish): Publish NPM packages in order of dependency tree

[Lms24]

Following up on #inc-456, this PR splits the previously universal npm target that took care of publishing all packages at once into multiple targets (one for each package).
This will ensure that packages are published in the correct order of their sentry dependency tree (e.g. core -> browser -> react, etc..) Furthermore, this theoretically also lets us disable the release of individual packages (which we might want to do if a package was already released).

In addition, this PR now moves NPM targets before other targets, so that no GH releases are created if the actual publishing of artifacts failed previously.

The drawback of this solution is that we have to manually add a new target for new packages we added. Therefore, this PR also adjusts our new package release checklist to do this before cutting the first release. Given that we had failing releases in the past because of incorrectly configured new packages, this might actually be beneficial.

With this change, craft is configured to process the following targets in the given order:

[
    "npm[@sentry/types]",
    "npm[@sentry/utils]",
    "npm[@sentry/core]",
    "npm[@sentry-internal/tracing]",
    "npm[@sentry/replay]",
    "npm[@sentry/browser]",
    "npm[@sentry/node]",
    "npm[@sentry/angular-ivy]",
    "npm[@sentry/angular]",
    "npm[@sentry/ember]",
    "npm[@sentry/react]",
    "npm[@sentry/svelte]",
    "npm[@sentry/vue]",
    "npm[@sentry/wasm]",
    "npm[@sentry/integrations]",
    "npm[@sentry/serverless]",
    "npm[@sentry/opentelemetry-node]",
    "npm[@sentry/nextjs]",
    "npm[@sentry/remix]",
    "npm[@sentry/sveltekit]",
    "npm[@sentry/gatsby]",
    "npm[@sentry-internal/typescript]",
    "npm[@sentry-internal/eslint-plugin-sdk]",
    "npm[@sentry-internal/eslint-config-sdk]",
    "npm[@sentry/hub]",
    "npm[@sentry/tracing]",
    "aws-lambda-layer",
    "gcs[browser-cdn-bundles]",
    "github",
    "registry"
]

We might want to further group targets to packages (and split up registry targets while at it) but I think for now, we try this publishing approach and avoid creating another ~25 additional targets.

I tested this new config locally with a local craft installation and --dry-run and it seems to pick up the correct packages for each target (and it'll error if a package was not found).

[Lms24]

Decided to also give this an id, as it's not apparent that this target uploads the CDN bundles

[mydea]

Amazing! Great work, this will hopefully help prevent problems in the future 🚀