Rework AugmentRuntimeType and Choice/Case linkage

Augmentations and their interactions with runtime linkage are a strange
beast. Not through YANG semantics, which is very simple. The
complication is Binding Specification reusing statement interfaces
across 'grouping'/'uses' boundaries. This poses distinct challenges as
for a particular GeneratedType we may have multiple augmentations,
which:
- may be completely unrelated. Binding Spec does not provide its usual
  compile-time safety guarantees because it basically says transporting
  anything across grouping boundaries is mostly okay as long as you
  augment all instantiations of the grouping the same way. That is a
  very sensible trade-off, as it allows, for example, no-frills movement
  of data from RPC 'input'/'output' and 'notification' structures to
  and from the datastore. More importantly it allows transportation
  across datastore subtrees, which enables very easy derivation
  pipelines
- but they have to obey YANG namespacing rules, which means that when we
  are interfacing towards yang.data.api (or any YANG-conforming
  projection), we have to make sure the constructs are aligned and also
  perform automated repair & recovery based on Binding Spec assumptions.

Current code behaves incorrectly in this respect, as it does not perform
correct expanstion of 'uses/augments' in one part, and then considers
all augments in when trying to look up a statement -- easily wandering
off into augments which are not appropriate through the YANG scope.

Fix this by correctly tracking with augments are valid in a particular
scope and carefully resolving them.

As a further side-effect of this, the choice/case relationship is
reworked to prevent potential recursion problems and rather expose the
ambiguos linkages in BindingRuntimeTypes.

We also separate CompositeRuntimeType from AugmentableRuntimeType, so
there is a clear distinction which types can be targeted by Augmentable
interfaces and which cannot.

JIRA: MDSAL-731
Change-Id: I027bbfa4ea8315b11b9348f5e0928626de3103a0
Signed-off-by: Robert Varga <robert.varga@pantheon.tech>