Make inst_to_dict and dict_to_inst recursive

[pafuent]

Fixes #6533

Making GDScript inst_to_dict/dict_to_inst utility functions recursive.
Adding also a new macro to validate the number of the required arguments.

[pafuent]

Please pay special attention to my poorly attempt to document the changes that I did to inst_to_dict and dict_to_inst methods

[Mickeon]

If I recall correctly, methods like Array.duplicate() have a hardcoded limit of 256 to prevent the infinite recursion.

[pafuent]

@dalexeev I addressed your comment

[pafuent]

Friendly remainder

[dalexeev]

Sorry for the long delay. I left a few comments, but they don't need to be fixed. I have doubts about whether we should make inst_to_dict() and dict_to_inst() recursive. Perhaps we should deprecate these functions instead. Let me explain why.

1. You implemented recursive representation only for object properties, but nested objects can also be array elements and dictionary keys/values.
2. Arrays and dictionaries can be typed, so they also need to be represented in a special way (say, as {"@type": "Array", "@elem_builtin_type": "int", "@elements": [1, 2, 3]}). Because we can't, for example, put a dictionary representation of an object into an Array[Object].
3. Arrays, dictionaries, and objects are passed by reference. Currently, inst_to_dict() creates a shallow copy, and all reference types in the dictionary representation are the same values ​​as in the original object (see example below). If we make a deep version of inst_to_dict(), it would probably have to create duplicates, because of p. 2. This would be inconsistent with the flat version, which is essentially a separate serialization function with different behavior, hidden in inst_to_dict() behind an optional parameter.
4. We already have other serialization functions: var_to_bytes(), var_to_str(), and the new JSON functionality (see Ability to convert native engine types to JSON and back. #92656). I think 4 types of serialization is too many. var_to_str() has security concerns, but it seems like the new JSON methods are aimed at being more secure (at least they have appropriate parameters). I think we should focus on the core serialization methods and deprecate the GDScript specific inst_to_dict() and dict_to_inst() functions.

class Test:
    var a = []

func _ready():
    var test = Test.new()
    var dict = inst_to_dict(test)
    print(dict) # { "@subpath": ^"Test", "@path": "res://node.gd", &"a": [] }
    print(test.a) # []
    dict.a.append(1)
    print(dict) # { "@subpath": ^"Test", "@path": "res://node.gd", &"a": [1] }
    print(test.a) # [1]

[dalexeev]

Looks like you accidentally deleted DEBUG_VALIDATE_ARG_TYPE(0, Variant::OBJECT); and DEBUG_VALIDATE_ARG_TYPE(0, Variant::DICTIONARY); when rebasing the PR.

[pafuent]

Those two checks are now made on the recursive versions _inst_to_dict and _dict_to_inst respectively

[Ivorforce]

I have doubts about whether we should make inst_to_dict() and dict_to_inst() recursive. Perhaps we should deprecate these functions instead.

I don't disagree. I'd like to know what a typical use-case for these functions is (or at least what they are currently being used for). Perhaps @pafuent can comment on that? I do occasionally use python's vars(), though that creates a shallow dictionary.

[pafuent]

To be honest the only use case that I know is to serialize/unserialize data

[pafuent]

Thanks for the reviews and explaining thoroughly why this methods should be deprecated!!! (I really appreciate it)
Closing it because its superseded by #99121