Rework Resource Handling in Node Exports

[CoolSpy3]

Description
This PR unifies the various methods for re-relativizing resource urls when a node is exported to another format. This should fix a few bugs and make the code more uniform/easier to maintain in the future. Specifically:

• The string-based handling that was previously being used for proto exports has been removed. Instead, when exporting to a proto, nodes will use the same code that was previously used for w3d exports. This fixes the resolution of resource paths in nested protos (see Resources missing when convert to base nodes of Tiago robot #6851) and allows for a more-targeted system that only affects urls that are known to point to resources, excluding any extraneous paths that end up in the generated proto.
• The resource resolution/export code has been centralized in WbNode and the field export system has been updated to make it easier for nodes to specify custom field export code. This should make everything a bit more readable, and it fixes some cases where fields would be exported twice.
  • As a side-node, I also cleaned up the logic in the various implementations of exportNodeFields, so they all look relatively similar. Notably, this fixes a bug where a TrackWheel exported to a proto would not retain any of its fields. (There may have been some similar bugs for other export modes, but I didn't look explicitly for them. Regardless, the new system should fingers-crossed not have any of those problems.)
• A couple of other nodes (WbCamera, WbContactProperties, WbMotor, WbSkin) used various resources, but did not have any special export code. I've added it in. This means that these nodes will now download their resources when exported to w3d.
• Finally, there were a few locations where WbUrl::exportResource was called with the same raw and resolved url. (1 2 3) In unifying everything, I've updated the code to pass the actual raw url. Assuming I understand the code correctly, this should not cause any change in behavior as WbUrl::exportResource only uses the raw url to parse out the file name; not its path.

Related Issues
This pull-request fixes issue #6851

Tasks
Add the list of tasks of this PR.

• Update the changelog

[omichel]

The test suite is repeatedly failing on this PR. Can you check it?

[CoolSpy3]

I think the failures are unrelated. The linux failure is caused by robot_window_html (see #6755), and I'm pretty sure the Windows failure is a result of the general flakiness of the Windows tests:
Run 1) Failed to download dependencies. This was probably caused by a temporary server outage or network problem. Waiting and rerunning the test resolved it.
Run 3) Failed due to an artifact download error. I have no idea what caused that because the logs report that the build task succeeded and the artifact was uploaded successfully. I'm willing to chalk it up to a bad run.
Run 2 and Run 4) Both failed due to backward_compability_enu_flu (the test passes, but 'Webots exits abnormally'), which has also been consistently failing on other PRs (ex. #6755 and #6758) [with the same error code]. Weirdly, however, that test passed in #6853, which is the most recently merged PR. This makes me think that it's a result of a dep bump somewhere. (A runner update was released on the same day, but it looks unrelated.) Even weirder, in this branch (and only this branch) the CI has also been hanging on the windows test. I have no idea how these changes would cause that, but I'll try manually disabling the failing test to see if that clears it up. Fwiw, all of the tests pass on my local windows machine, so I'm not all that sure where to investigate. I'll maybe try to setup a Windows Server VM and see if I can repro the bug there, but I won't be able to get to that until at-least this weekend.

[CoolSpy3]

Setting up a local actions server was a bust, but I've managed to reproduce the crash on normal Windows. It occurs after closing the window (or, presumably, unloading the test) after nested_mixed_template_proto in a release (not debug) Webots build. Given that it doesn't occur in debug, I'm having some trouble tracking down the source. I'm going to try and hack together a release build with debug symbols, and hopefully that'll give us a path to solving the underlying problem 🤞

EDIT:
It worked! Stacktrace:

#0  0x00007ff77ce2dc52 in WbAbstractPose::detachTranslateRotateManipulator (this=<optimized out>) at nodes/WbAbstractPose.cpp:313
#1  0x00007ff77cd2d9c7 in WbSelection::selectNode (this=0x4550370, n=0x0, handlesDisabled=false) at app/WbSelection.cpp:74
#2  WbSelection::clear (this=0x4550370) at app/WbSelection.cpp:146
#3  WbSelection::clear (this=0x4550370) at app/WbSelection.cpp:144
#4  0x00007ff9253ea6ae in ?? () from C:\msys64\mingw64\bin\Qt6Core.dll
#5  0x00007ff77ceeeb95 in QMetaObject::activate<void, WbBaseNode*> (sender=0x10ea8ab0, mo=0x7ff77d030280 <WbBaseNode::staticMetaObject>, local_signal_index=0, ret=0x0)
    at ../../include/qt/QtCore/QtCore/qobjectdefs.h:306
#6  WbBaseNode::isBeingDestroyed (this=0x10ea8ab0, this@entry=0x111e1bb0, _t1=0x11229b90, _t1@entry=0x111e1bb0) at build/release/WbBaseNode.moc.cpp:163
#7  0x00007ff77cb293ae in WbBaseNode::~WbBaseNode (this=0x111e1bb0) at nodes/WbBaseNode.cpp:75
#8  0x00007ff77cbcecfb in WbGroup::~WbGroup (this=<optimized out>) at nodes/WbGroup.cpp:57
#9  0x00007ff77ccac3a7 in WbPose::~WbPose (this=0x111e1bb0) at nodes/WbPose.cpp:57
#10 WbPose::~WbPose (this=0x111e1bb0) at nodes/WbPose.cpp:57
#11 0x00007ff77cc43d73 in WbMFNode::~WbMFNode (this=0x10e661e0) at vrml/WbMFNode.cpp:37
#12 0x00007ff77cc43dce in WbMFNode::~WbMFNode (this=0x10e661e0) at vrml/WbMFNode.cpp:38
#13 0x00007ff77cbb6873 in WbField::~WbField (this=0x10e66700) at vrml/WbField.cpp:78
#14 0x00007ff77cbb692e in WbField::~WbField (this=0x10e66700) at vrml/WbField.cpp:80
#15 0x00007ff77cc71533 in WbNode::~WbNode (this=0x10ead310) at vrml/WbNode.cpp:257
#16 0x00007ff77cb293ce in WbBaseNode::~WbBaseNode (this=<optimized out>) at nodes/WbBaseNode.cpp:78
#17 0x00007ff77cbceda4 in WbGroup::~WbGroup (this=0x10ead310) at nodes/WbGroup.cpp:57
#18 WbGroup::~WbGroup (this=0x10ead310) at nodes/WbGroup.cpp:57
#19 0x00007ff77cc43eb9 in WbMFNode::clear (this=<optimized out>) at vrml/WbMFNode.cpp:67
#20 0x00007ff77cd42f09 in WbSimulationWorld::~WbSimulationWorld (this=0x10e2f2f0) at nodes/utils/WbWorld.hpp:88
#21 0x00007ff77cb6fa3e in WbControlledWorld::~WbControlledWorld (this=0x10e2f2f0) at control/WbControlledWorld.cpp:64
#22 0x00007ff77caf5626 in WbApplication::~WbApplication (this=0x262dae0) at app/WbApplication.cpp:114
#23 WbApplication::~WbApplication (this=0x262dae0) at app/WbApplication.cpp:122
#24 0x00007ff77cc2d7bd in WbMainWindow::closeEvent (this=0x2682a10, event=0x5fc530) at gui/WbMainWindow.cpp:1062
#25 0x00007ff92370a258 in ?? () from C:\msys64\mingw64\bin\Qt6Widgets.dll
#26 0x00007ff9236b630c in ?? () from C:\msys64\mingw64\bin\Qt6Widgets.dll
#27 0x00007ff9250e9ae0 in ?? () from C:\msys64\mingw64\bin\Qt6Core.dll
#28 0x00007ff92370539e in ?? () from C:\msys64\mingw64\bin\Qt6Widgets.dll
#29 0x00007ff92371671e in ?? () from C:\msys64\mingw64\bin\Qt6Widgets.dll
#30 0x00007ff9245af460 in ?? () from C:\msys64\mingw64\bin\Qt6Gui.dll
#31 0x00007ff9236b630c in ?? () from C:\msys64\mingw64\bin\Qt6Widgets.dll
#32 0x00007ff9250e9ae0 in ?? () from C:\msys64\mingw64\bin\Qt6Core.dll
#33 0x00007ff924557224 in ?? () from C:\msys64\mingw64\bin\Qt6Gui.dll
#34 0x00007ff9245b2103 in ?? () from C:\msys64\mingw64\bin\Qt6Gui.dll
#35 0x00007ff9252aeb46 in ?? () from C:\msys64\mingw64\bin\Qt6Core.dll
#36 0x00007ff924913a49 in ?? () from C:\msys64\mingw64\bin\Qt6Gui.dll
#37 0x00007ff9250f5d85 in ?? () from C:\msys64\mingw64\bin\Qt6Core.dll
#38 0x00007ff9250f3d1a in ?? () from C:\msys64\mingw64\bin\Qt6Core.dll
#39 0x00007ff77cff15c7 in main (argc=<optimized out>, argv=0x25bec70) at gui/main.cpp:218

I'll see if I can come up with a fix...

Edit 2: I figured it out! Fix is on DeepBlueRobotics/webots:fix-destroy-order. I'll write up the PR tomorrow. (See #6857)