Allow choosing typed Arrays and Dictionaries when adding or editing metadata

[Synzorasize]

Describe the project you are working on

I am saving my save files as a native Resource with metadata as it doesn't have a script. The Arrays and Dictionaries within the metadata hold the Resources (aka save data) that are used in the game.

Describe the problem or limitation you are having in your project

The Arrays and Dictionaries are still typed when serialized and loaded, but the inspector does not seem to recognize this as it shows an untyped collection. When adding new entries, I have to select the type manually, which can be cumbersome when testing or debugging save data. Also, choosing a Variant which the typed Array or Dictionary does not allow leads to unexpected behavior.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

The inspector can be updated to recognize typed Arrays and Dictionaries in metadata the same way it does for object properties.

Also, when adding new metadata, when Array is selected, another dropdown can appear allowing you to choose the element type. By default, it will be Variant. Similarly with Dictionary, two dropdowns can appear allowing you to choose the key and value types.

The first suggestion may be enough to suffice if the metadata is simply being created through code and then being edited through the inspector, but it may be helpful in some cases to implement the second suggestion as well.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I believe you simply have to port the code to recognize the object properties to also recognize typed collections in metadata for the first suggestion, but I could be wrong. The second suggestion may be more complex, but starting with the dropdown that is used in the inspector may be helpful.

If this enhancement will not be used often, can it be worked around with a few lines of script?

If the metadata is only being edited through code, then this issue won't arise, but if it is being edited through the inspector, then solving this issue would allow consistency with the object properties' behavior in the inspector.

Is there a reason why this should be core and not an add-on in the asset library?

It would be more intuitive to have this in core.