ensure_usable_cors_rules() isn't client friendly

Feature Request

Motivation

We are using tower-http in our project and we allow users to configure CORS. If there is a mistake which we can't detect in the composition of those rules, then this can result in a runtime panic in the ensure_usable_cors_rules() fn. This is not a good experience and we are working around this at the moment by validating our CORS rules before we pass them into tower-http.

Proposal

Could we modify ensure_usable_cors_rules() so that rather than asserting rules are usable, returns a result and expose this function so that we can validate before attempting to create a CorsLayer?:

    pub fn ensure_usable_cors_rules(&self) -> Result<(), &'static str>;

Alternatives

Perhaps have a try_layer() on Cors (or CorsLayer?) which is a fallible CorsLayer creator? If we had this, we could keep the original assert based ensure_usable_cors_rules() and add a new private fallible ensurer for consumption in try_layer. I feel like this would be the cleanest solution.

Locate ensure_usable_cors_rules() and the CorsLayer creation path, then read the existing CORS tests around invalid rule combinations. Determine which proposed fallible API fits the current public interface; done means invalid rules can be validated without a runtime panic and the behavior is covered by tests.