RPC spec: try to define a little more semantics and extensibility for `data`.

IIUC: Previously, error.data was meant to be the serialized error object from Arti. As such, it was specified to be deliberately unstable, and likely to change.

This didn't seem like such great idea, especially as we started to come up with structured and stable data that we did want to put in error.data.

With this commit I'm taking a new approach to error.data. Specifically:

  * `error.data`, if present, is always an object.
  * Unlike before, it can have multiple keys.
  * The keys of `error.data` are always namespaced.
  * There is a requirement that documentation exist for every key in
    an`error.data` document, including the type, semantics, and
    stability of its values.

There is also new "anticipated use of error.data" section to clarify our plans:

  * We plan to use error.data deliberately when it actually
    serves a purpose, and not as a catch-all dumping ground
    for every field in a Rust error.

  * We don't plan to have an on-by-default serialization or Debug of
    every Arti error.  (If we wanted an optional one, there is a
    short sketch of what it might look like.)

Part of work on #1662 (closed).