CC address improvement (outdated)

1. Changing cc scriptPubKey to use cc address instead or condition
Currently there is an issue with the cc technology that it generates cc addresses which actually are unusable: there is no way to send cc value to a cc address - we always need a pubkey to pass it to a cc rpc and create a transaction with cc outputs for this pubkey. This confusing users who could get cc addresses with an rpc or see them in the explorer.
But we can fix this if change CC scriptPubKey: now it contains a fingerprinted condition but we may put there the R-prefixed CC-address by hash160-ing the cc condition. Then we could create cc vouts using only CC-addresses (without pubkeys, which is more user friendly).
The scriptSig is unchanged. The evaluating code just need to hash160 additionally the condition evaluated from the fulfilment (from the. scriptSig) to compare it with CC-address in the scriptPubKey. The current spk/scriptSig structure:

scriptSig: <fulfillment>
scriptPubKey <condition> OP_CHECKCRYPTOCONDITION - evaluates the fulfilment and compares it to the condition 

The proposed spk/scriptSig structure:

scriptSig: <fulfillment>
scriptPubKey <cc-address> OP_CHECKCRYPTOCONDITION_V21 - evaluates the fulfilment, hashes it and compares it to the cc-address 

2. Multisig destination addresses
Another problem is with multisignature cryptocondition addresses: currently we could not tell to which addresses a multisig cc vout is sent. We pulled code from Verus that deals with this, but it was not compatible with our cc address structure. They actually add pubkeys in OP_DROP and use them to create R-addresses extracted in ExtractDestination(). Their R-addresses are not derived from cc conditions but just simply normal addresses. We use cc addresses in the indexes and the Verus method of address extraction from cc outputs broke our indexes - so we disabled this extraction.
But we may go the same way like Verus (that is, extract destinations from the pubkeys in OP_DROP to show where the vout sent) but we can create correct cc addresses (that is, hashed from conditions). So we would see actual multisig destinations in the explorer or command line rpc, and users could see multisig amounts in their balances.
There is a technical problem: how to construct a vout to obtain the matching condition - this is specific for each cc. For this we need to add in each cc module a virtual function that would return cc address for an output, using the OP_DROP data: pubkeys and some hints like evalcodes and funcids.