Rework NormalizedNode class hierarchy and design

NormalizedNode interface has a number of deficiencies, which make it non-trivial to use and implement.

Most notably:

1. it uses generics to capture identifier type and value type
2. it generalizes that all NormalizedNodes have value, which would seem to indicate it can be used for comparison, but
3. NormalizedNodeContainer.getValue() codifies it to a Collection, which wrecks equality contract, and
4. That contract is not really accurate, as all implementations really want to say Set, but they are also implementing the contract through a Map, which does not have a valueSet() and entrySet() actually is not useful

While we cannot get rid of the generic type for identifier type (as it leads to Identifiable<T>), we should eliminate the notion that a raw normalized node has a value and reserve that to ValueNodes only. Furthermore the notion of children being present needs to be abstracted towards the end specializations, so they can provide an accurate view based on semantics.

For NormalizedNodeContainer this amounts to replicating java.util.Map contract, with the inherent understanding that children are unique based on their identifier – essentially the map there interpret NormalizedNode as an Entry<node.getIdentifier(), node> when adding them. Note that NormalizedNode cannot be an Entry, as it inherently would violate the Entry.hashCode() contract.