Suggestion: Give the possibility to install a cap without a signature in a transaction payload

[CryptoPascal31]

Currently: In a transaction payload, a capability is always associated to a signer (pubKey) and a matching signature. It does make a lot of sense because most of the time, a capability code enforces a guard.

But in some cases the capability doesn't enforce any guard, and just need to be installed. One of these particular cases is in gas station triggered by the magic cap GAS_PAYER. Since this usually triggers a public gas station, it is a non-sense to associate GAS_PAYER to a pubKey. However, this is mandatory with the current Chainweb/Pact implementation.

Currently for a client or a Dapp there are 2 possible workarounds to make it work:

• If the transaction contains already a signer with an already restricted signature, attach GAS_PAYER to the existing signer. From a functional point of view this is completely inconsistent. It just breaks the beauty and the concept of capabilities.
• Create a fake signer, with a fake key pair just to install a capability that doesn't need a signer. This is stupid and inefficient.

I think that Chainweb should allow and always validate a payload containing a Signer object with an empty pubKey. In this case, I suggest to use a special marker like "NONE" or "NOVERIFY"in the scheme field, to indicate that signature verification must be bypassed.

NB: Not sure if this should be handled directly by Chainweb code or Pact code.