Update the LoadServerList Transpiler

[Xilophor]

Replaces the cached lobby query, which can become out-of-sync with the lobby query used by the LoadServerList method & postfix due to the nature of async methods. This update changes the caching of the lobby query (clone) to a new local variable in the LoadServerList method which stores the lobby query (clone) and can be pulled out when calling the "postfix."

• Removed the RequestAsync prefix
• Removed the list of cached query distance & string filters
• Added cloning & storing of the lobby query in the LoadServerList transpiler
• Changed the LoadServerList transpiler to be better formatted

[legoandmars]

Looks good at a glance, I'll have to test it in game to make sure all filtering works as intended

[MaxWasUnavailable]

Is this up to date with the main repo? I see some removed properties that are in the other PR.

[Xilophor]

Is this up to date with the main repo? I see some removed properties that are in the other PR.

It's up to date, this PR removes some of those properties that were only used as a "cache" to keep the query info, but with the updated transpiler those are no longer necessary.

This does still need testing (I'll see if one of y'all are up for it tonight).

[Xilophor]

Because of the way async methods work, between "states", or await calls, and variables that are carried between them have to be stored in the instance of the compiler-generated class. The compiler will automatically generate these "state" fields only for variables used by multiple states.

There lies the issue, the lobby query local variable is not used by multiple states, so the compiler does not store the value in a "state" field. Therefore, the local variable is not saved between states, and is null when we attempt to pull it out in the post-fix.

The three solutions available are what we currently have, preload-patching the method, or an "in-between" solution, where we store the lobby query variable in a dictionary of the async class instance and the LobbyQuery struct.

For now I'm closing this PR as the method we have works, even if there are very unlikely edge-cases. We can come back and implement either the in-between solution or the preload-patcher solution, sometime after initial release.