Restore Immutable ID scheme and routes

I'm opening a new ticket, since we have a few in this vein that are scattered around, but the underlying issue is general, as well as being easy to fix.

A brief summary of the issue:

(Before state)

• Evergreen provides ids for various records that are immutable – explicit API
• Evergreen requires users to create a project with some id; this enforces that users specify something that makes sense to them – explicit API
• Evergreen formats child record ids based on the parent record ids – observed API (Hyram's Law)
• The id/reference/link for a given record is predictable – observed API
• The id/reference/link for a given record is user-friendly – observed API
• It is easy to interrogate and consume Evergreen data, even outside the context of Evergreen – observed API

So, people will call something "sys-perf-v5.0" or "mongodb-mongo-v5.0", and there is a fan out of workflows and tooling that integrate with the above APIs. Now, people will of course want to rename it to "system-performance-5.0" or "mongodb/mongo-5.0". So clearly they would like some kind of mutable identifier.

There are a couple ways to allow for the mutable identifier:

• similar to display_name, attach it as metadata to the project record for reporting purposes
  • Insert above points/features of Evergreen, they all hold true still
  • Updating workflows/tooling/integrations/models is opt-in, since the change is entirely backwards compatible
  • Supporting links/routes based on project_identifier is still possible

• refactor our domain model, to use the mutable identifier as the main reference for a resource (the currently implemented strategy/requirements).
  • Evergreen provides ids for various records that are immutable – explicit API
  • Evergreen provides mutable identifiers – explicit API
  • Evergreen doesn't require users to create a project with some id; this enforces that users specify something that makes sense to them UUID used by default. – explicit API
  • Evergreen formats child record ids based on the parent record ids mutable identifiers – observed API
  • The id/reference/link for a given record is predictable – observed API
  • The id/reference/link for a given record is user-friendly – observed API
  • It is easy to interrogate and consume Evergreen data, even outside the context of Evergreen – observed API
  • Updating workflows/tooling/integrations/models is opt-in, since the change is entirely backwards compatible
  • Supporting links/routes based on project_identifier is still possible

The strikethroughs above have led to broken integrations and hacks across tooling (see linked tickets). We need to remediate that now.

AC/Requirements:

• Ensure all immutable ids are human-friendly.
• Generate mutable ids from one another based on the previous parent-child schema. Do not attempt to generate references based on mutable data.

In terms of implementation, you can likely copy the display_name code, and add some routing support for that as a non-breaking change.