LNPBP-11, 12, 13: RGB public state transitions

Right now only parties owning some of RGB contract state (i.e. able to spend an UTXO with some assigned RGB state data, i.e. close a seal over next state) can update the state with state transitions. While this is very strong "anarcho-capitalistic" smart contract system, there are cases when independent third parties should be able to modify/interact with smart contract, for instance "decentralized issuance" (which can be used in bitcoin-backed RGB bitcoin derivatives, when anyone in the world can lock some bitcoins to some pre-defined Miniscript template-based UTXO and produce RGB asset). However, in order to have these assets interoperable (and issuance being decentralized) we need all these actions to happen under some single genesis, whence anyone can extend smart contract history after genesis with this issuance procedure.

Here I propose how this can be achieved with a simple RGB modification, which adds a lot of new use cases to the core of RGB (like "call a method of RGB smart contract").

First, we introduce that genesis and state transitions, additionally to state assignments with single-use seals, may contain (if Schema allows) a vector of so-called **opened valencies**. Each *opened valencies* is a "public extension point" of some Schema-defined type: it is not linked to any UTXO and anyone can create a RGB node of special structure (**public extensions** of RGB state) connected to such valences. Moreover, there is no limit on how many *public extensions* can connect to a single *opened valences* type (and such limits can't be enforced).

*Public extensions* has structure similar to *genesis* and *state transitions* structure with the following differences:
* like genesis, they do not reference any *ancestor seals* (since there are none)
* they link to a specific type of *opened valences* from previous state transition or genesis (which must define *opened valences* of that type, otherwise *public extension* is not valid)

Like any other type of RGB state history *node* (genesis and state transitions) they can have new state assignments with seals defined (thus, creating new state rather then updating existing one, like done in genesis), metadata and simplicity scripts; their structure and validation rules are defined with the Schema and Schema-provided simplicity scripts.

Similar to *genesis* (and unlike *owned transitions*) *public extensions* are not committed into bitcoin transactions, thus being **ephemeral** until some other *owned transition* closes one of it's seals/updates their state, after which they become committed into bitcoin transactions graph through that transition. In practice this means that publicity can update RGB contract history only if some of state owners is willing to accept those updates, which will include the new state into future subgraph starting from such RGB state history node.