Serial integers are bad error codes

Currently, error codes are seemingly added on the basis of "the last error code plus one". This is bad because it means entirely unrelated errors are placed next to each other. In general, errors about the same topic would ideally have similarities in their encoding.

We have a few plausible directions here:

0. Shrug and embrace chaos
1. Use a numeric encoding of the expected error space akin to SQLSTATE or HTTP status codes
2. Switch to using text-based error codes using extant diagnostic slugs or something similar
3. Switch to using text-based error codes resembling something like the reference's dotted-keys: https://doc.rust-lang.org/reference/identifiers.html#r-ident.syntax
4. Nuke --explain

User feedback is consistently that at least some --explain outputs are helpful, so we probably shouldn't do 4 (incl. survey responses to direct questions at #t-compiler > Error codes still useful? @ 💬). The usual "and also..." we get is the --explain output is most useful in the earlier phases of learning Rust.

We probably shouldn't do 0 either. If nothing else, a serially increasing integer leads to merge conflicts as described in #t-compiler > Error codes still useful? @ 💬.

We probably will have to allow both error code schemata to coexist for a while since a "hard" migration would be very rough on our codebase, testing infrastructure, and programmer expectations. We'd even break integrations like evcxr's, which uses error codes because they are more robust than pattern-matching specific error messages. https://github.com/evcxr/evcxr

Start by reviewing the compiler's existing error-code assignment and --explain behavior, then read the linked compiler discussion and survey responses. Consider the compatibility requirements for evcxr and the proposed period of coexistence between schemas. Done means selecting and documenting a concrete error-code direction with a migration plan.