chore: Move --force-publish flag to new release:server flag.

Having the `--force-publish` flag on `npm run release` made sense
previously, but now that federation and gateway are part of this repository,
we'll probably want to come up with something a bit more refined.

Back-story: It's important to keep the integration packages (e.g.
`apollo-server-express`, `apollo-server-hapi`, etc.) in lockstep versioning.
In order to do that, one day - amidst some release shuffling frustration —
I just realized that the `apollo-server-core` was previously the
"most-depended-upon" package, so this made sense to use that because it
would force all the integrations to also update to use its new version,
while avoiding the overzealous `--force-publish=*`.

There's another option here, and I think I know what it is, but given that
federation and gateway are now settled into this repository, I want to make
sure we don't release `apollo-server-core` and _every_ integration every
time we release a new version of `@apollo/federation` or `@apollo/gateway`,
so this change a bit, for now.

The short-term of this is: if you're releasing a new version of Apollo
Server, it would likely be better to use this new `npm run release:server`
command.

Releasing federation should be similar, but I'm not entirely sure how we're
going to manage to not publish new patch-y versions of Apollo Server with
various Renovate package dependency updates (which have landed here and
there) when we're just trying to release federation or gateway.

This would probably be much less of a concern if we went all in on
conventional commits, but there's also a certain annoyance to new versions
of `apollo-server` just being released all the time by (other) consumers of
automatic package dependency update systems (like Greenkeeper and Renovate).

That said, I'm almost tempted to adopt conventional commits to help everyone
understand the scope of changes and understand the intended risks!

Anyone should be safe to release, I think.  If in doubt, publish from
branches with isolated changes to packages and merge it (don't squash it,
please, because of Git tags' importance to Lerna) back into the main trunk
(`master`).  It's always a safe bet to branch from the last published
version (i.e.  `release-2.6.0` as of this commit message.)

:palm_tree:; :wave:.

cc @trevor-scheer @jbaxleyiii @JakeDawkins @martijnwalraven

package.json

@@ -8,7 +8,8 @@
     "compile": "tsc --build tsconfig.build.json",
     "compile:clean": "tsc --build tsconfig.build.json --clean",
     "watch": "tsc --build tsconfig.build.json --watch",
-    "release": "npm run clean && npm ci && lerna publish --exact --force-publish=apollo-server-core --include-merged-tags",
+    "release": "npm run clean && npm ci && lerna publish --exact --include-merged-tags",
+    "release:server": "npm run release -- --force-publish=apollo-server,apollo-server-azure-functions,apollo-server-cloud-functions,apollo-server-cloudflare,apollo-server-express,apollo-server-fastify,apollo-server-hapi,apollo-server-koa,apollo-server-lambda,apollo-server-micro",
     "postinstall": "lerna run prepare && npm run compile",
     "lint": "prettier-check '**/*.{js,ts}'",
     "lint-fix": "prettier '**/*.{js,ts}' --write",