Optimize RenderComponent destroy

[Maksims]

RenderComponent has a property rootBone, which is just a reference to an entity, that is used for skinning. Currently, it uses overcomplex EntityReference which creates a number of event handlers in various systems, which is extremely inefficient. rootBone - is a simple property that just is either null or some Entity.
When creating/destroying entities, EntityReference has to subscribe and unsubscribe to a number of events, which leads to an unnecessary workload.

So this PR just simplifies rootBone property, which does not change any behaviours. While optimising destruction of all RenderComponents (not skinned especially!!).

Here are test results, of destroying 4706 entities with RenderComponents (not skinned, primitive cubes):

Before: 640ms
After: 84ms

This is ~7.5 times speedup, or ~87% improvement.

In our use case, we need to parametrically create a lot of entities, and remove them on user interaction, so any lag spike is extremely noticeable. I've also noticed that changing rootBone when an entity is disabled, will not be taken in account when an entity is enabled, but this is an existing current problem and should be fixed in a separate PR.

Also, a lot of other components use EntityReference, which is best to go. It is unnecessarily complex and inefficient.

I confirm I have read the contributing guidelines and signed the Contributor License Agreement.

[willeastcott]

I'm not a massive fan of having types differ for a single setter/getter pair. The previous type of rootBone was Entity. Seems correct to also allow null. Was the old type definition wrong for not specifying string was valid too?

[Maksims]

Yes. Old definition was wrong, as it was accepting strings and actively does it.

[Maksims]

asset accessor does the same with asset id.

[willeastcott]

LGTM. Nice! 👏 Are you gonna do a follow up to get this merged to main?

[Maksims]

LGTM. Nice! 👏 Are you gonna do a follow up to get this merged to main?

I'm happy for the team to do the cherry-picking and manage multiple versions on their own.
Not sure that it is friendly to outside contributors to ask them to manage multiple versions as I'm for example am not familiar with v2, and we don't use it yet as it is not available in Editor, so I cannot test this PR against main, only main_v1.