Implement Fast Level Loading

[DashingCat]

This PR implements "Fast Level Loading" (like Fast Texture Loading, but for levels).

In collabs, levels can take a lot of time to load (especially since texture loading times have already been improved).

The implementation uses Parallel.For (which uses CPU core count as degree of parallelism), is enabled by default (this could be changed), and logs level loading order (to help diagnose potential issues).

It adds a ThreadStatic attribute to stringLookup in BinaryPacker, so each thread has its own lookup.

It also adds a lock in MapData, because map data processors from mods don't expect concurrent access and may fail.

During testing, these changes improved loading times on my end, loading "Strawberry Jam Collab" levels takes about 6 seconds before changes, and about 4 seconds after changes.

[JaThePlayer]

Very nice! Would probably be a good idea to add some virtual bool IsThreadSafe => false; to MapDataProcessors, so that mods can work towards thread safety for their processors. If all registered processors are declared thread-safe, then the lock could be omitted and we'd probably see a larger perf boost. (And perhaps add some logging for non-thread-safe processors so we know what's blocking us?)

[DashingCat]

Very nice! Would probably be a good idea to add some virtual bool IsThreadSafe => false; to MapDataProcessors, so that mods can work towards thread safety for their processors. If all registered processors are declared thread-safe, then the lock could be omitted and we'd probably see a larger perf boost. (And perhaps add some logging for non-thread-safe processors so we know what's blocking us?)

Thanks!

From my testing (on the "Strawberry Jam Collab"), the locking doesn't have much impact on the performance boost (less than half a second).

I'm not sure getting mods towards thread safety in their map data processors is needed at this point, because it could lead to issues if mods are declared thread-safe but aren't in practice; and thread synchronization issues can be hard to diagnose and fix.

[Wartori54]

Looks good other than my comment, will approve once it gets resolved.

[Wartori54]

Perhaps we should ship it as disabled by default, advertise it once it lands on stable, and schedule a PR to make it enabled by default once some time has passed. In order to prevent what already happened with the fast FMOD loading.

[DashingCat]

Thanks @Wartori54 for the feedback, the latest commit adds a toggle for the feature in the "Mod Options", which is disabled by default.

A future PR could then set the field FastLevelLoading to true.

[Wartori54]

I think it's better to keep this as = null, so that migration is easier. This allows us to freely change the meaning of the null value without having to modify the users' settings file.
I can't quite remember how is bool? handled in the in game ui, some extra work may be needed ui wise to get this to work.

[DashingCat]

Thanks, these comments were addressed in the latest commit; bool? are not handled in the "Mod Settings" UI but a custom handler was made.

Significant changes in PR