to extend polkadot/caip10 to include "implicit/not-yet-derived" CAIP-2

[bumblefudge]

I realized that "polkadot:-:{address}" scheme would break CAIP-2 because - is no more a valid chainID than or null would be; then I re-read Tim's comment and realized I had misinterpreted it!

In any case, I'm still not sure this complexity is justified by real polkadot usage so I'm going to leave this PR open until I hear from people that have experience of that ecosystem and its practices.

[bumblefudge]

Update: since caips#160, - (or rather, ---) could now be a valid CAIP-2. This might be a little too much "wildcard" for existing CAIP implementations, but I am generally favorable to this kind of pattern, as I have some use-cases in mind for namespace-wide checking of wallet identity (independent from chain-specific balance, for example)... pipe up if you'd like to see this finished and merged, polka-people! NB @paritytech

[bumblefudge]

in terms of wildcards and non-chain IDs in the chainId segment of CAIP-10, there is now precedent in another namespace that may be relevant to this PR:
#107