EF should warn or prevent users from seeding large amounts of model data #29395

EF should warn or prevent users from seeding large amounts of model data. There should also be clear way to undo damage caused by seeding large amounts of model data in the past.

Per https://learn.microsoft.com/en-us/ef/core/modeling/data-seeding#limitations-of-model-seed-data
It looks like users shouldn't seed using model data if a large amount of data is entered.

This isn't obvious, especially for novice users. If an instance of large model data is missed, especially for a while, the problem grows exponentially as each successive migration creates an additional large designer.cs (>10MB in some cases), causing build times, build resources, and code analysis to crumble under the weight and complexity of these files.

Additionally, especially if custom migrations have been used in the path, there doesn't seem like a great way to resolve a mistake like this. [This issue, squash migrations](https://github.com/dotnet/efcore/issues/2174), has been and continues to be outstanding (seemingly deprioritized) and many related issues have been closed.

Example issues I think could be related:
- [Migrations build issue after .NET 5 installed dotnet/efcore#23426](https://github.com/dotnet/efcore/issues/23426)
- [.Net 5 EF Core database create is much slower than .Net Core 3.1 dotnet/efcore#23574](https://github.com/dotnet/efcore/issues/23574)
- [Extremely slow build for asp.net core 3.1 apps dotnet/efcore#23435](https://github.com/dotnet/efcore/issues/23435)
- [Very high memory consumption during build (4GB) with binary log enabled dotnet/efcore#2168](https://github.com/dotnet/msbuild/issues/2168)

GitHub questions:
- [C#: Out of memory during dotnet build after migrate to NET 5](https://stackoverflow.com/questions/69224616/c-out-of-memory-during-dotnet-build-after-migrate-to-net-5)
- [.net core 2 app long build time because of migrations](https://stackoverflow.com/questions/64698016/net-core-2-app-long-build-time-because-of-migrations)
- [How to handle huge efcore migrations designer files that is slowing down build and IDE](https://stackoverflow.com/questions/52627277/how-to-handle-huge-efcore-migrations-designer-files-that-is-slowing-down-build-a)

If trying to create a repro solution, create a migration with a large amount of model data and then a number of migrations after and seen the size of your project grow exponentially in size with each successive migration, especially if more model data is added.

Redundant, but I think this "story" expresses the importance of resolving this clearly:
Undetected large seeded by model migrations lead users to experience poor build times and resources usage as well as degraded IDE performance (especially noticeable in JetBrains Rider when finding usages for EF data objects) as well as code analysis resource and performance in general. Users will [likely](https://www.google.com/search?q=dotnet+%22build%22+uses+too+much+memory) [turn off code analysis](https://stackoverflow.com/a/69359226) for projects and builds both locally and on build servers as those are the first suggestions when C# builds start using significant resources and time. Additionally, the problem may still be invisible to them unless they know what to look for. Resources required to build the project will grow exponentially with each successive migration until the issue is discovered, likely when IDE or builds begin maxing out a user's computer's memory (or other team member's less computer's memory), which may be months form when the issue was initially added leaving the team with a large know of migrations to untangle with unclear guidance of how to approach it.

Because of this many migrations, and potentially many releases, may be completed before the problem is detected. At this point, EF documentation doesn't provide any clear answers or solutions for users in this situation, especially if custom migrations have been used. Users should be prevented, or at least clearly warned, from making a mistake that will so obviously negatively impact their project.

EFCore should ideally prevent or at least warn users about creating migrations with models with large datasets (e.g. list of states, counties, or other even larger datasets)

Ideally EFCore would provide a clear way to fix migrations with large datasets checked added many migrations ago.