Feature addition policy

Each addition to the beacon API carries a significant implementation and maintenance cost, since in general, there's an expectation that beacon nodes actually will implement the API as specified.

As such, we should consider the requirements for any new additions to the common API so as to manage expectations with users and keep implementation burden reasonable.

A couple of ways this can be done:

* minimal approval requirements - ie at least N clients commit to implementing the API by approving it
* minimal released implementations - ie features are not merged until a client release exists supporting the feature (to ensure that we don't add features that are unimplementable or that nobody actually is willing to implement)
* explicitly experimental / extension API (to manage user expectations around API stability)
* this is similar to how the engine API defines a "required" of the more general JSON-RPC API - modules can creatively be used for "special-interest" features such as distributed validator middleware etc

While many features are obvious (ie hard-fork related updates to BN/VC interface), others are more nuanced - it is trivial to keep adding things to a standard, but much harder to remove or change things.

In general, it's fairly cheap to keep things in PR until they pass minimal QA bars such as above - the PR serves as implementation guide for early adopters avoiding fragmentation while at the same time making it easy for implementers to track what is "usually" supported by clients and what is not.

The issue names no files, tests, or entry points. Start by reviewing how the beacon API currently handles additions and the related pull requests, then determine which approval, released-implementation, or experimental-API requirements should be adopted. Done means the project has agreed on a policy for managing new common API additions.

Written by the indexing model from the issue text.