Unsustainable build times due to ent package size

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior

We have ~100 ent schemas and it takes over a minute to build the generated ent package on a relatively powerful MacBook Pro M2. (Note this doesn't include code generation time or time related to gqlgen!).

Since the ent schema imports the generated code for certain features, this means a build is sometimes necessary before the code generation even begins (which itself takes at least 30 seconds for ent and another 30 for gqlgen). This is particularly painful when hitting (frequent) merge conflicts which always require a rebuild (cache miss).

On less powerful machines, our devs tend to just go for a walk when ent generation starts, as it completely eats up their system resources, largely because of the build/compile portion. This also greatly slows down our CI agents.

Expected Behavior

Much faster builds when only a small portion of the ent schema is changing. The Go build cache should be leveraged with smaller packages. For example, if each schema's client was in its own package, and imported by the main ent package, only clients that changed would be rebuilt. Go is known to have fast build times, but ent is just so large. Arguably ent could be reworked to generate less code for the same functionality, but that is a larger problem to tackle.

Steps to Reproduce

Just have ~100 schemas with a number features turned on (like gqlgen) I used go build -debug-actiongraph=/tmp/actiongraph to get package build times. ent was by far the slowest

Your Environment

Tech	Version
Go	1.21.8
Ent	0.13.1