Discussion: Consider using configuration options to register modules

Consider a registration experience like this:
```csharp
builder.Services.DiscoverAndRegisterModules(c =>
{
c.SolutionName = "eShop2";
c.AutoDiscover = false;
c.RegisterModulesFromAssemblies(typeof(IUserService).Assembly); // blatantly _borrowed_ from MediatR
c.RegisterModulesFromAssemblyContaining();
c.SetConfiguration(builder.Configuration);
c.SetLogger(myConsoleLogger);
// .... OR

c.AutoDiscover = true; // default
c.RegisterModulesFromAssemblyContaining();

});
```

Lots of packages use this _configuration_ style to handle setup.
If nothing is passed, it would use sensible defaults, but it gives the user to option to override certain behavior of the registration process.
While also avoiding having to keep passing in potentially more and more optional parameters as the feature set grows.

Examples of features would be:
- Allowing users to skip auto discovery (for those that are concerned about performance)
- Setting the IConfiguration and Logger (so that it doesn't have to pre-build the service builder
- Altering module names to exclude/ignore

The issue names no files, tests, or current registration entry point. Start by locating the existing module-registration API and reviewing the proposed configuration options; done would require an agreed design, implementation scope, and corresponding tests.

Written by the indexing model from the issue text.