Consider rewriting SK2 WebAPI into ASF's WebBrowser

[JustArchi]

Mainly due to lack of strong-typing, with JSON deserialization I can ensure fixed and expected structure with all per-property logic, with SK2 I need to check everything on my own and ensure there are no anomalies.

I still need to decide whether this is worth the actual effort, since both approaches have their own pros and cons, but since I need to have working implementation for everything else already, there is little point in keeping yet another abstraction in form of SK2's WebAPI.

[JustArchi]

@Abrynos what do you think? 🤔

[Abrynos]

Seems like a good idea to rewrite this. As they will probably become more I'd suggest moving the classes in ArchiSteamFarm/ArchiSteamFarm/Json/Steam.cs to seperate files as well

[JustArchi]

I'm putting this on hold until we get a grasp on what is actually a correct approach in SteamRE/SteamKit#641

Steam's API is so crazy that it might actually make far more sense to depend on SK2 handling this madness rather than me adding yet another features to WebBrowser, this time for sending binary POST content.

[JustArchi]

After required fixes in the encoding logic, I find no reason anymore to go with this suggestion. Steam API has a lot of quirks that I wouldn't easily workaround without using SK2 (such as encoding in ISteamUserAuth), therefore I sacrifice response verification for encoding and handling low-level details for me.

Since I'm fan of abstraction levels and prefer to have SK2 in charge of talking with Steam API (instead of doing that myself), I'm keeping current approach due to no outstanding advantages, and at least several reasons against.