Refactor server project to use .NET Generic Host to remove code smells

[Measurity]

Describe the issue

Server code has the following code smells:

1. Server starts and loads from files through DI container instead of what is conventional: loading after the DI container is fully resolved. Types registered in a DI container should not do IO until asked for by code that takes dependency on said types.
2. The dependency-flow on data is inverted from what it should be (is parent->child but should be child->parent). Types like WorldPersistence should take dependency on Server (which knows its SaveName) instead of recomputing the save location. The current situation has lead to awkward DI container setup where types need to run setup code to be able to register in the DI container.
3. Strongly related with 2: because file loading happens during DI container setup, cancellation of server is hard to implement (without first waiting for the server to fully load).

To assist with this refactor, the server should implement .NET Generic Host API.

Then:

1. Rename the Server class to ServerService, extending BackgroundService. Have it figure out the save name from command line arguments (passed to the server executable).
2. Create a ConfigService which depends on ServerService and loads in the right server.cfg file based on the save name that ServerService knows. Any updates to the configuration should happen through this ConfigService.
3. Create a WorldPersistenceService which depends on ServerService to figure out where it should Load, Save and Backup to. If there is no world, have it create one in WorldPersistenceService.StartupAsync routine. Add events/dependencies to other services as needed to trigger world backups or saving.
4. Create a CommandService that will read from the command line and call the correct command on submit (i.e. enter pressed).
5. Continue creating APIs that depend on ServerService or any other as needed...

PRs required before work can start

• Improve linux support (new launcher) #1848

[Jannify]

Should then also fix the Lazy<> part of #2106 described here #2106 (comment)