Delete assets after artboards to fix race condition with FileAssetRef…

…erencers.

I caught a random crash in Unity. Our unreferencing logic has a race condition! This is probably causing crashes in a lot of the runtimes, randomly.

We attempt to unregister a file asset referencer when the FileAssetReferencer is destructed here:
https://github.com/rive-app/rive/blob/d708e6a07b454ce0fc20d9432172f2b58c9f29f7/packages/runtime/src/assets/file_asset_referencer.cpp#L10-L13

This causes invalid memory access if m_fileAsset has already been deleted. This can happen when the source artboards stored in a file get deleted. Doesn't affect instances, but any-time a whole File is destructed this race condition can occur. We store our artboards and file assets as lists in our File object. Because they are stored in vectors as unique ptrs, we aren't guaranteed destructor order (some compilers will destruct the list of artboards first and some will destruct the files first). I've seen Clang do both (in Windows it was destroying the assets first which causes the problem as the references in the artboard then try to access the file assets).

We should be really cautious when accessing bare pointers in destructors and make sure we understand the lifecycle of any objects we're referencing during destruction.

For now this is the cleanest immediate fix, ensure that destruction is done in order:
1. Artboards and their components first
2. File assets
3. Backboard

We introduced this here: https://github.com/rive-app/rive/pull/6068

Diffs=
18ae32102 Delete assets after artboards to fix race condition with FileAssetReferencers. (#6223)

.rive_head

@@ -1 +1 @@
-252100f48a796caa0199b65339e0def4d2eb676c
+18ae3210288344019381946136b5dc0474c3eb35

.rive_renderer

@@ -1 +1 @@
-1a94c2a317c02d772235a037b411bfa1ec69e540
+fc0c3470d710fbcadc6cc394764b697a850745c3