Onion routing support for coming stealth transactions

With the impending completion of Stealth capabilities, it makes sense for us to support connecting to API servers through TOR or I2P. On the I2P side of things, the Monero team is working on Kovri, and it may warrant looking into when it is complete (currently alpha status). TOR support can be enabled now. Functionally, there is absolutely nothing preventing it from working - I have tested by running the Desktop client in a Whonix Workstation VM (this transparently proxies all internet access through TOR), it was able to connect to a temporary onion server on my personal API node without any issues other than a higher than normal latency - which while it may be problematic for trading, should not be a big deal for transacting.

I think the ideal way to implement this would be similar to how the Monero team is planning on using Kovri (over there, blocks will get relayed clear webs, but transactions via i2p onions). We could do something similar, where all data related to stealth transactions is onion routed (possibly borrowing from how Bisq uses local onion services to listen for connections), while that relating to the transparent public ledger would continue to be sent as it is now.

IMO, it should be done as transparent as possible to the end user as it can be without compromising on privacy.

No files, tests, or entry points are identified. Start by locating the client’s API connection and stealth-transaction paths, then review how proxy or onion-service connections could be configured. Done means a decided, tested approach for routing stealth-transaction data through TOR or I2P without disrupting transparent-ledger access.

Written by the indexing model from the issue text.