GetComponent and Get*FieldByName protoflux nodes

[bdunderscore]

Is your feature request related to a problem? Please describe.

Currently, there is no way to obtain and write to a particular field of a particular component given the containing Slot in protoflux - apart from ref hacking. This becomes a problem particularly when you want to create an easy installer for a gimmick that needs to access fields of, say, a component on a user or avatar - but don't want to require the user to open up the inspector for it.

Describe the solution you'd like

Three new nodes:

• GetComponent<T> => Takes a slot as input, returns the first component of this type on that slot (or null)
• GetValueFieldByName<T> => Takes an IWorldElement and string as input, locates a field by that name on the IWorldElement and returns the IField<T> if found (which can later be used in a FieldAsVariable, FieldHook, or Write node)
• GetReferenceFieldByName<T> => Same as above, but looks for a SyncRef<T>

Note that support for synced lists will require additional nodes once collections are implemented.

Describe alternatives you've considered

Ref hacking...?

Additional Context

I think this kind of functionality has been sometimes considered part of #572 . However, these specific nodes are 1) not dependent on collections functionality, and 2) still useful after collections are delivered, both for performance and usability reasons. In particular - even if there's a GetAllComponentsFromSlot or GetAllFields node, you really won't want to use that if you only want a single specific field of a single specific component, which is probably the more common usecase anyway.

Requesters

bd_ ...but probably many others as well (not finding a preexisting issue, but maybe I'm just not using the right keywords)

[Frooxius]

The reason we avoid adding those nodes before collections is because we want the whole API to be designed together.

Often what happens when we do a "shortcut" like this and add limited version is later when we expand upon it, we find design issues that are now baked in and hard to get around.

For big stuff like this, we want to spend time designing the systems and working through it and all its implications, so we won't be adding these piece-meal.