error codes for dropshot-provided errors need work

As it says in error.rs, we envision that errors from an API typically have a string code (separate from the HTTP status code):
https://github.com/oxidecomputer/dropshot/blob/308be874160569eb8cd6752c04216a914e650f2b/dropshot/src/error.rs#L52-L69

I've generally assumed that the namespace of these codes needs to be under the control of the Dropshot consumer, since they will likely be defining most of the codes for their own application-specific conditions. However, Dropshot currently generates a bunch of different errors of its own (e.g., when a request arrives for a path that has no handler associated with it). What code should it use?

I'm thinking out loud through a bunch of options here:

1. Have Dropshot define a set of codes for itself and let consumers use whatever codes they want, too. This kind of sucks. It's hard to expand Dropshot's set later since we might stomp on a code that consumers are already using. We could use a prefix to carve out part of the namespace, but this is part of the consumer's public API -- that's ugly. Plus, it's hard for Dropshot to make judgments about what error cases a consumer's client wants to distinguish.
2. Let the consumer define the entire namespace and allow consumers to define the codes that Dropshot will use for its own errors. Maybe the caller provides a function that maps HTTP status codes to Strings (or something that we can turn into a String). Or maybe Dropshot defines an enum for the conditions it needs to generate codes for and consumers provide a function that maps from that. We could even provide a default implementation that would hopefully be suitable for most consumers. This gives us most of the benefits of (1) but without the expansion problem -- if we expand it, if the consumer uses a match, they'll get a compile error that forces them to decide how to map the new condition.
3. Have Dropshot own the entire namespace: create a set of codes like ObjectNotFound, BadArgs, etc. and require that consumers use these. This might actually be nice because many consumers will wind up using a lot of the same codes, but it seems like a non-starter that consumers can't extend this.

The behavior today is that the code is optional and Dropshot generally provides None. That was basically a hack to be able to make forward progress -- it's pretty crappy for consumers and their users.

See also #39.

Start with dropshot/src/error.rs at the referenced lines and read the discussion in issue #39. Compare the proposed ownership and mapping options for error-code namespaces, then determine the consumer-facing behavior Dropshot should support. Done means the design is resolved and the resulting error-code behavior is implemented and covered by the relevant project tests.