Add asynchronous hint to entities [#5127]

[Beilinson]

Description

This is a draft PR attempting to solve #5127. The issue has comments mentions several use cases, I'd personally like to add the use case of "hover" behavior which currently requires either using callback properties (not efficient on the scale in our app) or the primitive API directly (difficult to support compatibility with the entire Entity API).

The basic concept of this PR:

1. Add getter-only asynchronous property to Entity and GeometryUpdater (analogous to the getter-only asynchronous property on Primitive), which defaults to true
2. Similarly, add the property to all relevant <TYPE>Batch classes. Each batch will pass its asynchronous flag to its internal Primitive
3. In the <TYPe>Batch.prototype.add method, when checking whether to create a new Batch, compare the asynchronous flags between the existing Batch's and the updater, similarly as is done for materials, zIndex, etc...

Questions:

1. All the Dynamic<TYPE>Updater classes always create a Primitive with asynchronous: false. I can't see the value in setting this to true, so most likely the flag on the Entity should just have a comment mentioning this. Should setting asynchronous: true on a graphics with a dynamic property throw a runtime/developer error?
2. The pipeline for polyline visualization is pretty different than most other geometry types, luckily StaticGroundPolylinePerMaterialBatch at least already supports an asynchronous flag it just isn't used. Other than that I think I can get it working there as well
3. Points, billboards, and labels have no such concept of an asynchronous creation state. Again I'm assuming that the flag having no effect here is a legitimate behavior. This leads me to the main question in terms of API design: should this be a flag on the Entity, or only on the relevant <TYPE>Graphics which even support asynchronous creation?

Issue number and link

#5127

Testing plan

Initial example

TBD

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

[github-actions]

Thank you for the pull request, @Beilinson!

✅ We can confirm we have a CLA on file for you.

[Beilinson]

I also think that the outline for this branch could apply perfectly to something like allowPicking, which is also pretty useful because the Entity api does not support this currently (#2895). I found #4410 which was closed with the following comment:

I'm going to close this due to inactivity. Thanks for the work you put into this @dwhipps! This just isn't quite the approach we want and we haven't had a chance to revisit a different strategy. Hopefully this is something we'll get to before too long.

However it doesn't seem that an alternative has been implemented, leading me to question whether that PR should maybe be reopened, although I do think it wouldn't work correctly with batches (but the method in this PR should work without issue).