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.
Rationale: Foil cards are excluded from STM, as the price varies. For most people with !IsBotAccount that will be main account, which should never be lootable, and for people running bots for friends, making them keep foils makes sense. The main reason for this change is my own setup in which I'd like to automatically send all cards to ArchiBoT for 1:1 matching, but keep foils for selling.
It seems that even if Steam responds with e.g. internal server error (500), the trade gets accepted 20-30 seconds later, which doesn't make ANY sense, but does anything in Steam do?
Let's improve the logic a bit by returning result even if we in fact failed in Accept/Decline function, this will allow us to deal with confirmations even if failed trade in fact succeeded.
Modification of ASF.json is troublesome when I work with GitHub tree, therefore make it possible for me to execute and test commands but only in debugging builds - public ASF releases are always compiled in release mode.
The objective of this feature is to detect network malfunctions as well as SK2 connection issues early and initiate a reconnect as soon as possible, instead of relying on failures in SK2 code.
This is because those failures are very usually coming too late, when connection was already lost for a dozen or more minutes behind, and it also increases likehood of getting weird SK2 freezes like the one in #318.
Therefore, let's see how it works, it's possible that I'll revert it later when SK2 code improves or we find a better way to do that. The introduced overhead both CPU-wise and bandwidth-wise is negligible.
