Generated builder cpu/memory efficiency

The builders we generate are not entirely memory/cpu efficient. Specifically the way augmentations are retained is sub-optimal, creating undue pressure. A typical object looks like this:

private static final class TlvsImpl implements Tlvs {

public Class<org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.pcep.types.rev131005.open.object.open.Tlvs> getImplementedInterface()

{ return org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.pcep.types.rev131005.open.object.open.Tlvs.class; }

private final OfList _ofList;
private Map<Class<? extends Augmentation<org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.pcep.types.rev131005.open.object.open.Tlvs>>, Augmentation<org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.pcep.types.rev131005.open.object.open.Tlvs>> augmentation = new HashMap<>();

private TlvsImpl(TlvsBuilder builder)

{ this._ofList = builder.getOfList(); this.augmentation.putAll(builder.augmentation); }

Note how "augmentation" allocation is disconnected from the actually filling – this potentially inefficient. So move the allocation from field to constructor, so we can size the map appropriately.

Second, most of augmentation instances end up being empty or only a few entries. So check for these circumstances and allocate optimized versions of these maps:

switch (builder.augmentation.size()) {
case 0:
this.augmentation = Collections.emptyMap();
break;
case 1:
final MapEntry<...> e = builder.augmentation.entrySet().iterator().next();
this.augmentation = Collections.singletonMap(e.getKey(), e.getValue());
break;
default:
this.augmentation = new HashMap<>(builder.augmentation);
}

This change is API-safe and should be applied to hydrogen/stable as well.