Consider providing common mechanism for tenanted services to report tenant misconfiguration

In situations where configuration for a particular service in a particular tenant is wrong, it can be hard to diagnose, because the problems might be nested a few levels deep. (E.g., `Marain.Workflow` uses `Marain.Operations`, and in a situation where the delegated configuration for operations is wrong, it'll be `Marain.Workflow` that receives the error when it tries to use `Marain.Operations`.)

In practice, working out what has happened in these cases has proven tricky.

It might be possible to make it easier to understand by introducing an exception type to represent this broad kind of problem, e.g. `TenantConfigurationException`. This would be thrown by code that understands the configuration requirements for a particular piece of configuration. For example, `BlobContainerSourceWithTenantLegacyTransition` knows the (somewhat subtle) rules for whether tenanted storage configuration is correct. It could throw an exception indicating unambiguously that we have a tenant which is misconfigured.

This would open the door for higher-level code such as Menes to be able to recognize this exception, and provide more helpful information back to callers than we currently get. (Right now, we just get a generic 500 failure.)

Start by examining the tenant-configuration rules in BlobContainerSourceWithTenantLegacyTransition and how errors propagate to higher-level code such as Menes. Determine the exception contract and reporting behavior needed for callers to identify tenant misconfiguration rather than receiving a generic 500. Done requires an agreed mechanism that works across tenanted services.

Written by the indexing model from the issue text.