Deprecate PrimitiveMesh.custom_aabb and ArrayMesh.custom_aabb

[CrayolaEater]

There is a redundancy in the custom_aabb property shared by the PrimitiveMesh, ArrayMesh resources, and GeometryInstance3D.
I don't see the point of having 2 separate properties that do the same thing.
Also, GeometryInstance3D.custom_aabb can be visible because of this #89538.

Note: I also did a workaround for the PrimitiveMesh.custom_aabb and ArrayMesh.custom_aabb: when setting those properties now the GeometryInstance3D.custom_aabb will also update (making the custom_abb visible)

[clayjohn]

There is a very good reason to have custom_aabb on meshes. When a mesh uses a material that alters its size (for example by using the grow option in StandardMaterial3D or by using a ShaderMaterial), you need to use the custom_aabb to ensure the mesh AABB covers the entire mesh.

With this change, users would have to manually set a custom AABB on every single geometry instance that uses that mesh/shader. It is much better for users to set the custom_aabb once for the mesh and then have that automatically used by all GeometryInstances that use that mesh.

[CrayolaEater]

There is a very good reason to have custom_aabb on meshes. When a mesh uses a material that alters its size (for example by using the grow option in StandardMaterial3D or by using a ShaderMaterial), you need to use the custom_aabb to ensure the mesh AABB covers the entire mesh.

With this change, users would have to manually set a custom AABB on every single geometry instance that uses that mesh/shader. It is much better for users to set the custom_aabb once for the mesh and then have that automatically used by all GeometryInstances that use that mesh.

For the user to visualize the mesh it needs to be added to a mesh instance node anyway, so there will be a confusion to which custom_aabb to edit. There are also different scenarios which I'm not sure how the custom_aabb behaves (e.g. when you have a custom_aabb on the mesh resource and a different one set in GeometryInstance)

Right now I added a way for both properties to update when the resource custom_aabb changes, so should I remove the deprecation and only keep that?

I think the ideal way is to have the custom_aabb as a separate resource for each mesh to load separately. But thats way out of this PR scope.

[clayjohn]

For the user to visualize the mesh it needs to be added to a mesh instance node anyway, so there will be a confusion to which custom_aabb to edit. There are also different scenarios which I'm not sure how the custom_aabb behaves (e.g. when you have a custom_aabb on the mesh resource and a different one set in GeometryInstance)

The AABB of the GeometryInstance is an AABB that surrounds all the AABBs of every surface. It is calculated by taking the min and max extents of all the surface AABBs.

This becomes really important for things like particles and multimesh, since the GeometryInstance AABB encapsulates all the AABBs of all the instances. Every time an instance moves you have to update the GeometryInstance AABB (which is every frame for particles). Using GeometryInstance.custom_aabb allows you to skip those calculations (which is the reason we added it).

Right now I added a way for both properties to update when the resource custom_aabb changes, so should I remove the deprecation and only keep that?

No, we need both properties.