Stabilize PropertyLayer

[EwoutH]

Removes the warning that the PropertyLayer is experimental, and thus stabilize it.

It has been used in example models (projectmesa/mesa-examples#214), integrated in the cell space (#2319) and the visualisation (both standalone (#2336) and as part of cell spaces (#2430)) and in Mesa for almost a year (#1898) without needing API changes.

Note that while the PropertyLayer itself is stable, not all it's integrations might be, like the integration into the still experimental cell space.

[quaquel]

We need to resolve the coordinate system discussion raised in #2431 as part of the stabilization.

[EwoutH]

What would minimally be done to declare the current functionality stable?

(CC @wang-boyu)

[quaquel]

Resolve #2431.

Thinking about this a bit more and looking at the code, I would also move the property layer classes into their own property_layers.py file. Currently, mesa.space is over 1600 lines of code and hard to navigate. A challenge is to figure out how to abstract _PropertyGrid functionality in such a way that it becomes a mixin that can be used with both old style and new style grids. This move is actually needed in preparation of stabilizing new style spaces and ensures that we don't need to break the API in 3.1 or jump through weird hoops to not break it. We could deprecate from mesa.space import PropertyLayer in 3.0, already support from mesa.property_layer import PropertyLayer in 3.0, and make that the default in 3.1.

[EwoutH]

Yeah I was also thinking of splitting it out. We could do mesa.spatial maybe for if we want to add more spatial / CRS / geo stuff

[quaquel]

Yeah I was also thinking of splitting it out. We could do mesa.spatial maybe for if we want to add more spatial / CRS / geo stuff

I suggest underpromising by calling it property_layerand keeping the idea of integrating where possible stuff from mesa-geo as a possible over-delivery in the longer run. Remember, we have to life with the API choices we make on this for at least MESA 3.

[EwoutH]

That's why I was considering a more general name instead of a specific file for one single class.

[quaquel]

In my view it would be PropertyLayer and HasPropertyLayers (a refactor of _PropertyGrid that can also be used with newstyle discrete spaces).

[quaquel]

Just a quick remark: at the moment, property layers throw user warnings based on the dtype stuff. Its not possible to get rid of those, because of the hardcoded np.float64, this should be changed to float or the test before throwing the user warning should be changed. I prefer the former since for numpy np.float64 and the python built-in float are equivalent.