Add never_valid transaction parameter to permit proof-of-capability signing

[plaidfinch]

Is your feature request related to a problem? Please describe.

As a user of Penumbra, I want to be able to prove that I could perform some transaction without authorizing the transaction itself. Examples of situations where this would be useful:

• Validators can prove that they self-delegate
• Delegators can prove that they delegate a certain amount to a validator, in exchange for special services
• DAO members can prove they hold a particular token, in order to get access to services or goods
• etc.

If there was a way to prove capability of doing a transaction, without ever authorizing a valid transaction, then these use-cases would be unlocked. It turns out there is a backwards-compatible, non-consensus-breaking, straightforward way to accomplish this.

Describe the solution you'd like

1. Add a new field to TransactionParameters named never_valid, whose default value if absent is false, as is the default in protobuf.
2. Add a new consensus rule so that any transaction which would have been otherwise accepted but whose never_valid field is true is still rejected.
3. Add a method to the transaction planner to set the never_valid field to true.
4. Add an RPC to pd which checks a transaction for validity, returning at least one of three values, corresponding to the statuses: "invalid", "would have been valid except for the never_valid field", and "valid".

Having done this, users can prove that they hold at least a certain balance of a particular token by building a never_valid transaction which consists only of spends and outputs, which outputs the specified amount of the token to an ephemeral address, and then revealing the output action. A counterparty can check the proof using the RPC in (4), and all they will learn is whether or not the person had sufficient value to cover the revealed output, not their total funds, and not any other information about their wallet balance. Similar protocols can be used for partial disclosure of other types of on-chain capability.

Describe alternatives you've considered

This could also be accomplished by setting an incorrect chain ID or an already-expired expiry time, but neither of these solutions are as clean or easy to present to the user. It would be good for users to have assurance that they are signing a proof of capability which can in no circumstance ever be used to authorize a real transaction, rather than having to carefully inspect an approval dialog to ensure that the chain ID is bogus or the expiry height is past (a moving target!).

[hdevalence]

We don't want to do this, for three reasons.

1. We're in a feature freeze and don't want to add new features other than ones that are already planned.
2. We don't want to encourage users to sign transactions in order to prove things about their account state. This is a very dangerous antipattern, and having a special "valid-never" feature doesn't really mitigate it, because it relies on users understanding that they're signing something BUT that it won't have effect for some special reason.
3. The use cases listed are already supported by the existing transaction disclosure mechanisms