Update data folder validation for Drizzle projects

[Star-Fish-C]

Summary

Drizzle.Data's community branch now uses LevelEditorProjects for level editor project files instead of the old Levels directory.

This updates Rained's Data folder validation to require LevelEditorProjects instead of Levels when selecting an existing Data folder during first-time setup or from Preferences.

Currently, choosing a Data folder from the latest Drizzle.Data community branch can fail because Rained still expects a Levels folder to exist.

Changes

• Update first-time setup Data folder validation
• Update Preferences Data Path validation
• Update English documentation for required/optional Data subdirectories

Testing

• Ran dotnet build src\Rained\Rained.csproj /p:GL=ES --no-restore

[pkhead]

I'm pretty sure the function of the LevelEditorProjects and Levels folders have not changed. It's just that the Levels folder was removed from the repository; previously, it was just a folder that contained a .gitignore, as the Levels folder stores render output. I suppose you are right though that it shouldn't be required. Actually, technically nothing needs to exist for Drizzle to (theoretically) function, but the validation exists in part to make sure users aren't selecting the wrong folder out of confusion.

also, I think requiring LevelEditorProjects removes a layer of flexibility. well, Maybe it's somewhat strange for a user to have an installation where they have multiple Data folders merely to store different assets, and have all their projects in one central folder, but I think it's good that it's possible. The LevelEditorProjects folder is also not hardcoded into Drizzle unlike the Levels folder.

all in all, I think what should be done is that the LevelEditorProjects folder should be kept optional. The Levels folder will now also be optional, as per your PR. Test if Drizzle automatically creates the Levels folder when rendering. If not, ensure the existence of the Levels folder upon launching Rained.

(i would probably do this myself, if I were not busy painstakingly translating assembly code into C to implement the audio system of the Windows port of my own homebrew game. or finding a workaround.)