Centralized asset auto-export/auto-dumping for facilitating sync between team members

Is your feature request related to a problem? Please describe.
Is a suggestion to improve merging between versions of the projects from different team members, and help to reduce, detect and fix very easily and fast any sync problems between such versions.

Describe the solution you'd like
Have some kind of natural text file somewhere in the file than save on itself in somewhat of a readable languaje, all the scenes, prefabs, models and such you can find in the project.

Why is that?

Because most of the assets in stride are already text files in readable language than reference resources somewhere in the machine and work them somehow, i'm talking about, for instance, SpriteSheets, Models, prefabs, you name it, but this assets are distributed around the editor folders in different sub-folders and such, so in order to make projects easier to merge between different team members, this suggestion is to have a file than can be merged through text, (like using git or maybe using WinMerge or something similar) than can work as a save-state of the complete project in that regard, in order to make the merge of this file the only necessary thing to have two identical project from the assets perspective, (besides actually having the referenced files for the SpriteSheets or similar of course)

Think something similar to the GameSettings file, which is there in the folder of the project being called GameSettings.sdgamesettings basically floating in the space, and that's perfectly fine and kinda the point.

Apparently stride already have something like that but saved internally, so the suggestion will be to convert that in a file like GameSettings, or make somewhat of a dump of that db every time there are changes in the assets and also detect and proposefully load it every time the file is changed externally.

Readability is only necessary for this suggestion up to the point to make possible manual merging (with WinForms for instance), it doesn't need to be really readable to the fullest if that were an issue in implementation.

That way a team can have easy merging, being the case the guys are using git, or being the case the artists are using winrar and sharing the project by hand, anyone could be able to merge the projects in a very flexible and reliable manner with this change and i would say could make far, far easier to work for teams.

Additional context
I would think than improve the experience of working as a team in a better coordinated way and with better sync without spending in cloud for instance is like one of the things than Stride could do than other engines can't, because at least in some relevant cases, doing so will go against his business model (of the other engines).

In general we continue talk about how we will like than Stride could be a more well known engine, and i think that conversation is fine, but there is up to this moment no real difference or reason to really use Stride over other similar C# engines besides security, chance to modify things yourself and somewhat efficiency, which on itself aren't things in the general public eye, or even industry eye than are consider as an advantage all by themselves, industry for instance can have that modifications chance and support paying the premium of some of this other engines for instance to get that same services.

Something like this could make it easier to coordinate between team members, sync, and because of that make the times of development faster, which in time can make it a better candidate for both, gamejams and teams than will want to make something to drop on the market giving Stride3d more chances to be more used, and become better known.

Start by examining Stride's existing internal asset database and the GameSettings.sdgamesettings handling mentioned in the issue. Define the export format, how scenes, prefabs, models, and other assets are represented, and how external changes would be detected and loaded; done means a project asset state can be exported, manually merged, and reloaded reliably.