Ability for CORS domains to be evaluated at runtime via service

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

Situation: We have embedded resources that can be added to our customer's websites that run under domain ABC, and that needs to communicate with our backend that lives at XYZ. This is dynamic and we would not like to be creating separate policies for any domain any time we have a new customer.

We have a domain setup process where our customer's domains are stored on our side, very similar to allowing redirect urls of OAuth. This problem is conceptionally resolving an origin at runtime to decide if it's allowed for CORS.

Today, there are two options I can think of to allow the concept of Dynamic CORS origins evaluated at runtime:
1) implementing custom middleware - this middleware would have to re-invent the CORS wheel and fetchspec, not ideal.
2) Inheriting and overriding the exiting CorsService, ICorsService .Evaluate and .Apply methods and DI-ing that in place of the canned CorsService. (this is the option I'm using today)

some issues with option 2: We can't resolve any scoped services here, only transient/singleton, which can be a pain for multi-tenancy in some setups (namely ours). this leads to having to tack things on to the httpContext.Items array in other scoped middleware for use during the CORS policy step, which feels janky.

### Describe the solution you'd like

It would be great to have a policy option that has a Func<> able to load an IServiceProvider to resolve a service that decides if a domain was valid or not. I don't think scoped service is required here but a nice to have. This way a lookup service, caching, etc, can all be leveraged and injected at runtime when deciding if the Origin was valid and allowed for a CorsPolicy.

Think of this as the existing .SetIsOriginAllowed(domain => ) on steroids.

### Additional context

_No response_