Add service and method config

[glbrntt]

Motivation:

When resoling addresses, gRPC clients can discover configuration to use
published by service maintainers. This is in the form of 'service
config' and typically encoded as JSON. However the structure of the
config is a translation of the service config protobuf message using the
standard proto to JSON mappings.

This change expands on the existing MethodConfiguration to allow it to
be decoded from JSON and adds a ServiceConfiguration which can also be
decoded from JSON.

Modifications:

• Add additional properties to MethodConfiguration and make it
  Codabale
• Add ServiceConfiguration and make it Codabale
• Add a RuntimeError
• Add the service_config.proto message and its dependencies and
  generate these messages into the test module.

Result:

Service config and method config are more fully featured

[glbrntt]

This change is in two commits:

• the 'real' work in 76b5069
• update proto script and generate in d7aade2

[glbrntt]

This isn't actually a new file, it got moved but changed quite substantially, before the configuration only included the timeout and execution policy (i.e. retry/hedging).

[glbrntt]

These changes also have a bit of an impact on MethodConfigurations but I'll do those in a separate PR.

[glbrntt]

It might make sense to replace the ClientError and ServerError with this. They all have the same structure but differ only in error codes. WDYT @gjcairo?

[gjcairo]

Hmm my first guess would be it makes sense, but I do wonder if it would be useful from a user's perspective to be able to differentiate between client and server errors beyond the error codes. I'm thinking something like:

func wrapAndRecordMetrics(someClosure: () throws -> Void) {
  do {
    try someClosure()
  } catch is ServerError {
    // increase server error metric counter
  } catch is ClientError {
    // increase client error metric counter
  } catch {
    throw error
  }
}

But I'm not sure how realistic something like this would be, and I can't come up with any other obvious scenarios, so maybe it would make sense to replace them.

[glbrntt]

Forgot to reply to this one earlier: I don't know if that's useful because we now a third RuntimeError which can be thrown by either client or server so this sort of metric recording fails to be useful anyway.

[gjcairo]

LGTM overall! Left some very small nits/questions.

[gjcairo]

Nit: s/a error/an error

[gjcairo]

Hmm my first guess would be it makes sense, but I do wonder if it would be useful from a user's perspective to be able to differentiate between client and server errors beyond the error codes. I'm thinking something like:

func wrapAndRecordMetrics(someClosure: () throws -> Void) {
  do {
    try someClosure()
  } catch is ServerError {
    // increase server error metric counter
  } catch is ClientError {
    // increase client error metric counter
  } catch {
    throw error
  }
}

But I'm not sure how realistic something like this would be, and I can't come up with any other obvious scenarios, so maybe it would make sense to replace them.