Improve the PathImpl/NodeImpl memory allocation and hashCode computation

This issue is to centralize any ideas we could have about improving the situation of PathImpl/NodeImpl regarding memory allocation and hashCode computation.

hashCode computation

I also had a potentially interesting idea to reduce the cost of hashCoding the Path. We have a few nodes that have an invariant hashCode (considering that now the parent is not part of the hashCode anymore): at least bean nodes, return value nodes, cross parameter nodes.
Moreover if we moved the name at the end of the hashCode, we could also probably compute the property node hashCode from a static one + some calculations to add the name.

Memory allocation

Was wondering if we could move the parent out of the NodeImpl object itself. This would require moving the information currently stored in the parent (container information and so on) to the node itself so we would need to keep some sort of buffer for these information in the path (probably a good idea to revisit the path builder PR of Gunnar to have this information only when we are building the path). Note that we would probably need some sort of stack to store these information.

Not having the parent in the NodeImpl would help using static nodes for current situations (the bean node for instance) and thus reduce the creation of NodeImpl.