Privacy Issues: Using "shield" as-is enables correlation attacks and violates privacy

[AlwaysCompile]

Currently ZingoLib disallows sending funds until Transparent balances are Shielded into the Orchard pool if there is insufficient balance. This requirement violates the users privacy in multiple ways by impacting users anonymity set to creating correlation attacks against the user due to the way Shielding is implemented in the wallet.

How is Privacy Impacted

1. Requiring "shield" will collect all transparent UTXOs together and shield them to the Orchard pool. The user has no control on the amount that is shielded or the UTXOs that will be collected. The result is that this forced combination of UTXOs in a single transaction will broadcast to the world that those UTXOs belong to the same person, which may NOT be the intended goal of the user.
2. This workflow only allows shielding to Orchard pool. It makes shielding to the Sapling pool impossible. Orchard and Sapling pools have different privacy properties so a user may prefer the Sapling pool. They are not substitutble. The Orchard pool has different privacy properties than the Sapling pool. In the end, the user should be the one choosing which shielded pool they want based on their privacy needs.

How to Resolve the Privacy Issue

1. Do not require "shield", but instead let the user send to own address that is either Sapling OR Orchard. In this way change the wallet logic to allow sends to Shielded pools inside the same wallet and include the Transparent balance as part of the available balance for the send. This will allow the user to at least pick an amount that will not collect all their UTXOs, but only some of them, if desired. In addition, this will allow them to send to either Sapling or Orchard. In other words, allow partial shielding at a time to either sapling or orchard.
2. "Shield" command which operates on the entire balance should allow shielding to the Sapling pool if desired to.