Allow keying properties when selecting multiple nodes

[mihe]

MultiTrackDrifting.mp4

Currently it's not possible to key properties for animation tracks when having multiple nodes selected in the scene tree, as pointed out among the many quality-of-life improvements in this proposal (as "Add several tracks/keyframes when several nodes are selected").

This seemed fairly straight-forward to address, by simply allowing the keying to not only work on Node but also on MultiNodeEdit, which is exactly what this PR does.

One thing that's perhaps up for debate in terms of UX is what value should be put into the keys when you have multiple nodes selected, given that MultiNodeEdit will display the value from the first selected node, even if the values of the multiple nodes differ. It seemed to me that the most intuitive implementation was to have each node's respective value entered into their respective keys, rather than the value of the first selected node be entered into all nodes' keys. For this reason the p_value passed into AnimationPlayerEditorPlugin::_property_keyed is now ignored and fetched from each respective node instead.

(I would perhaps also argue that MultiNodeEdit shouldn't work this way to begin with, and should render the value/control in some other way when the values differ between the nodes, which I believe is how Unreal does it, and perhaps other editors as well, but that's a separate discussion.)

In the process of doing this I felt the need to create a new method in AnimationTrackEditor that would be similar to insert_value_key but which accepted a specific Node instead and found that there was already such a method, called insert_node_value_key, so I made use of that instead (with some tweaks). The only major difference between these that I could spot was the inclusion of make_insert_queue and commit_insert_queue in the old insert_value_key, which I left in the now refactored insert_value_key. I welcome feedback as to whether this approach might have some unintended consequences.

[mihe]

I figured it made sense to have insert_node_value_key and the now refactored insert_value_key be consistent in terms of not taking a value but instead just fetching the value based on the property name passed in, so I did just that. It'll be a tad bit slower obviously, but it's not a hot path anyway, and this new interface should leave less room for shooting yourself in the foot by mismatching the property name and value.

[KoBeWi]

Works correctly.

Could use a look from @TokageItLab

[TokageItLab]

Seems to be working well.

[akien-mga]

Thanks!