It seems that Valve actually accepts not one but several tokens generated close to the point of request being sent, so our 2FA code will be always valid for 1-2 more minutes after supposed timeout...
Thanks to that, we can guarantee some room for networking, but also make users more happy as they'll never get 2FA tokens no human is capable of entering in time
The general problem is a mix of a few things: The fact that we don't have much time before steam network disconnects us, if we connect to it and not send log in request in acceptable time, the fact that Steam API might be unavailable and not provide us with server time, and the fact that we must know that time to generate valid tokens.
Previous solution would simply generate token immediately without asking Steam API, and schedule update in background for later, so even if we had incorrect time and failure of first try, second try would usually come with the right clock. If not, eventually we'd succeed anyway.
However, it's possible to slightly improve that - we can generate 2FA code BEFORE even connecting to steam network, this way we have time to ask Steam API, and in worst case of API timeout we'll simply try with our own clock anyway, and if it succeeds, timeframe before connecting and sending logon request should be small enough to fit - in worst case of being on the edge of 30 seconds, we'll simply try again later.
Perhaps it'd also make sense to modify slightly MobileAuthenticator to block and wait in case code is expiring in less than 5 seconds, that could be cool too!
ASF is AnyCPU binary which means it'll run fine on both 32-bit as well as 64-bit OSes.
Up to today 32-bit runtime was preferred for ASF, as it uses less memory and can be faster than 64-bit equivalent.
However, in very busy environments it's easily possible for ASF to require even more than 2 GB of memory, and in addition to that extending our userspace to 64-bit can bring benefits on more modern setups.
Therefore, keep being compatible on both 32-bit and 64-bit OSes, but on 64-bit ones use actual 64-bit runtime instead of preferred 32-bit one.
In addition to that, optimize some unused references and other things while we're at it.
