Add MaxSingleQueryCollections

[SimonCropp]

Adds MaxSingleQueryCollections, which limits how many collections one SQL query loads. A single query joins every collection it loads, so each multiplies the rows returned for the others: a cartesian explosion.

Counts

• Collection navigations in Include and ThenInclude, including string paths. A collection restated to ThenInclude something below it counts once.
• Collections a projection returns, for example Employees = _.Employees.ToList(), including collections nested in them.

Does not count

• Reference navigations.
• A collection only read by an aggregate, like _.Employees.Count() or .Any(), which is a subquery rather than a join.
• Any collection in a split query, from AsSplitQuery() or UseQuerySplittingBehavior(QuerySplittingBehavior.SplitQuery). AsSingleQuery() overrides a context that splits by default.

It is measured while a query is compiled, like the other shape levels, and works with WithQueryComplexity, the log and throw level validation, and the model cache key.

Choices

• Log default of 1, so it logs from 2 collections. That matches where Entity Framework logs MultipleCollectionIncludeWarning, which only covers Include and goes silent once a splitting behavior is configured. Existing users will see new log lines for queries with two collections. It only logs, so nothing breaks. LoggingTests.LogDefaults changed accordingly.
• Binary break: the new parameter is last on the QueryComplexityLimits constructor, with a default of null. Existing source compiles unchanged, but assemblies built against the old constructor need a recompile.
• Nested collections count the same as sibling collections. Nested collections grow rows more slowly than siblings, which multiply, but counting both keeps the limit simple.

Known gaps

• Only Select projections are inspected, not GroupBy result selectors or SelectMany.
• OwnsMany collections, which are stored in their own table, are not treated differently.