Allow per-method instead of per-service gRPC permissions

We currently have a gRPC authInterceptor that checks whether the client calling a given gRPC method has permission to call methods on that service:
https://github.com/letsencrypt/boulder/blob/69ba857d5e52ea188011271ac5697401f9391414/grpc/interceptors.go#L509

We would like to make this more fine-grained, so that we can control these permissions at the method level, instead of the service level.

Within the actual validation method (linked above) this will be quite simple: don't drop the method name on the floor, and check a map that includes the method name. The harder part is deciding on a config format and exploding that config out into an easy-to-check map.

Config options include:

• a map of method name to list of allowed client SANs (pro: easy to convert into final map; con: potentially lots of repetition in the config)
• a map of client SAN to list of allowed methods (pro: easy to add a new client which only accesses a few methods; con: potentially lots of repetition in the config)
• either of the above, with a list of defaults at the top (pro: reduces repetition; con: easier to make mistakes, might not reduce repetition in certain circumstances)

Start in grpc/interceptors.go at the authInterceptor validation method linked in the issue, and trace how the current service-level permission configuration reaches it. Decide on and document a method-level config format, then make the configuration available as a map keyed by method and client SAN. Done means permissions can be controlled per gRPC method without discarding the method name.