Add an _dupicate() -> Resource virtual method to resources

[WeaverSong]

Currently, refcounted properties in custom resources (for example, an arrays, which are quite frequent) are always passed by reference to duplicated copies, making duplicate largely useless for custom resources. I'm proposing adding a virtual override that would be called for custom resources, returning the new resource thus created. This would allow implementing any custom behavior needed to duplicate custom resources.

[MGilleronFJ]

I had this issue as well and would like this to be exposed too. The generic duplicate behavior is also very slow, compared to what a tailored function can do. It's a virtual function in core, so it sounds like we should be able to override it.
As an example, I also had problems with that lack of override when considering adding UUID properties to special resources in my project, related to in-game saving. Since such IDs would have to be properties, that leads duplicate to also copy them, ending up with a situation where 2 resources with the same UUID now exist in the project, which is hard to workaround without compromising error-checking in different situations.
Surely you could use your own duplicate function in code, but duplicate is used automatically by Godot, especially in the editor, so you can't always control that.
So generally this is a performance issue but also a functional issue.

However, before we just expose that as-is, there is another problem to explore:
duplicate does two things. It creates a new instance of the object AND copies properties of the first to the second. This is important, because if we allow to override duplicate like a virtual function, the implementor is now forced to not only copy its own properties, but also all inherited properties, and eventually scripts or extensions attached to it. And if you use inheritance, all most-derived classes have to do this as well. This is not great. Unlike usual virtual methods approach, you can't just call the parent method and then do your own logic, because that would mean each parent method would create an instance of the object. Creating the instance must happen only once.
Maybe this is fine in cases where you really want to override the behavior of parent classes. But if you don't, we would need the following:

Instead of virtual _duplicate, have _copy_properties_to_duplicate virtual method, meant to work in tandem with duplicate. The behavior of duplicate now being to create the object, and then call _copy_properties_to_duplicate. That method can then decide to call its parent or not at each level of inheritance.
All good? Well...

If the resource has a script, and we want properties of the script to be copied using the default behavior, we would have to run Resource::copy_properties_to_duplicate. Would that mean it would run the default implementation? If yes, it would negate all our efforts to customize it in child classes, if it uses get_properties_list and copy everything. A seemingly simple solution would be to restrain that function to only care about the current classes' properties and not child ones, but then that requires every class to "implement its part". That's actually not too bad, because it also improves copy performance: get_property_list not having to get invoked for all classes, or at all; and no use of generic get/set, which are slow too; and every class has the opportunity to copy its contents efficiently. The downside is maintainance cost, because properties are no longer automatically detected. It's easy for a missing copy to be forgotten. It requires more riguor and a bit more code when making changes. Maybe it would make it easier if it was quick to get only properties of the current class so the same default would run at each level, but not sure if that's possible.

If we don't want to go that route and just allow to override _duplicate, we still have to deal with the problems mentionned earlier.
Set aside the annoying burden of having to override duplicate in every class that overrides OR inherits from a class that overrides it... how can one, for example, decide for a property to be handled differently (if builtin flags are not enough)?
The only solution I can think about unfortunately revolves around re-implementing the quasi-entirety of Resource::duplicate in every class that wants to override duplicate... with just the custom change on top and tweak to exclude it from the default behavior. Anything less than that requires making assumptions about the use cases (i.e you could just create a new instance, copy what you think is necessary and return, but then what about scripts, what about parent classes, what about extensions, what about sub-resources etc; when you make a plugin, these things matter).

But what if you duplicates nodes? They have a duplicate function too after all? The plot thickens here, because implementation is different: https://github.com/godotengine/godot/blob/96be44c0ec4bafcb08d78be1a584b751b424db9f/scene/main/node.cpp#L2808
And I dont think that stuff is exposed. But I havent had the use case of doing that, so I'm not sure what to say about it. There is surely some overlap in the kind of problems to solve.

Personally, I initially preferred the first solution (splitting object creation from its copy) as I think it would be ideal (and reflects what I've been doing when I needed "duplicate" functionality in my projects, not necessarily Godot), but considering the existing codebase/philosophy and unless I'm missing options to improve the idea, the second solution ends up simpler overall, it is conservative. It puts all burden on the implementors though, so maybe helpers could make the job easier to avoid mistakes. Though I can't comment about nodes...

Some examples of custom resource duplicates in core itself:
https://github.com/godotengine/godot/blob/96be44c0ec4bafcb08d78be1a584b751b424db9f/core/io/stream_peer.cpp#L561 (potential future issues: you can't attach a script to StreamPeer or have an extension class deriving from it, it won't be duplicated here.)
https://github.com/godotengine/godot/blob/96be44c0ec4bafcb08d78be1a584b751b424db9f/core/io/image.cpp#L4108 (same with Image, though arguably the need is unlikely)