feat: entity companion definition static thunk

[wschurman]

Why

We're seeing an increasing number of circular reference reports caused by the requirement to maintain the companion definition singularity/singleton property in the application, usually by defining it in a module-top-level property. This has historically caused issues due to some properties in the companion/configuration using top-level definitions of entity types or other classes.

In the past, we fixed this piece-by-piece, making the companion definition or configuration fields that could cause circular references functions so that circular references would be less likely. #89 #93

This PR expands upon this but should fix it once-and-for-all by maintaining the singleton requirement in the framework itself rather than pushing the responsibility to the application.

How

This PR does a few things sequentially (yet procedurally) to accomplish the goal:

1. getCompanionDefinition -> defineCompanionDefinition - this signals to the application developer that this is a definition and that the framework will handle the singleton.
2. Instantiate a companion definition instance in EntityCompanionProvider. This will serve as the instance of the entity companion for the entity and is responsible for making this a singleton. Note that this doesn't need to be a singleton since these are objects, but since this method is called so frequently this memoization is a nice speedup.
3. Make all companion definition accesses occur through EntityCompanionProvider, for example: viewerContext.entityCompanionProvider.getCompanionForEntity(EntityClass).entityCompanionDefinition.entityConfiguration.tableName
4. Change thunk fields of EntityCompanionDefinition and EntityConfiguration to non-thunks due to the top-level being a thunk itself and accomplishing the lazy evaluation.
5. Move entity instantiation to EntityLoader.constructEntity to make it type-safe and prevent needing to access companion definition in the entity instances themselves (which would be infinite loop). This requires changing the constructor signature for Entity itself but that shouldn't be an issue since it is so rarely used outside of the framework itself.

Test Plan

Run all tests.

Also yarn link this into a large codebase (Expo www) and ensure that this fixes circular issues and doesn't break anything.

[codecov]

Codecov Report

Merging #210 (1ed704f) into main (2069a0d) will decrease coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #210      +/-   ##
==========================================
- Coverage   95.94%   95.92%   -0.02%     
==========================================
  Files          81       81              
  Lines        2094     2088       -6     
  Branches      282      283       +1     
==========================================
- Hits         2009     2003       -6     
- Misses         79       84       +5     
+ Partials        6        1       -5     

Flag	Coverage Δ
integration	95.92% <100.00%> (-0.02%)	⬇️
unittest	95.92% <100.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...xample/src/entities/AllowIfUserOwnerPrivacyRule.ts	100.00% <ø> (ø)
packages/entity/src/EnforcingEntityLoader.ts	100.00% <ø> (ø)
packages/entity/src/EntityAssociationLoader.ts	100.00% <ø> (ø)
packages/entity/src/EntityFieldDefinition.ts	100.00% <ø> (ø)
packages/entity/src/EntityMutationInfo.ts	100.00% <ø> (ø)
...s/entity/src/EntityMutationTriggerConfiguration.ts	100.00% <ø> (ø)
packages/entity/src/EntityPrivacyPolicy.ts	97.26% <ø> (ø)
packages/entity/src/EntitySecondaryCacheLoader.ts	100.00% <ø> (ø)
.../entity/src/ViewerScopedEntityCompanionProvider.ts	100.00% <ø> (ø)
...ages/entity/src/ViewerScopedEntityLoaderFactory.ts	100.00% <ø> (ø)
... and 23 more

... and 1 file with indirect coverage changes