Treat property builders for nested @AutoValue types more like property builders for collections. If we have `ImmutableList<String> strings()` and `ImmutableList.Builder<String> stringsBuilder()`, then the list starts off empty. If you never add anything to it, the final result is an empty list. Likewise, if we have `NestedAutoValueType foo()` and `NestedAutoValueType.Builder fooBuilder()`, then `foo` starts off with its default value. If you never set anything in fooBuilder(), the final result is a default NestedAutoValueType. We only construct that default value lazily, so if you do in fact set something on the builder then the default instance of NestdAutoValueType is never constructed.

This fixes a bug: previously if you never called fooBuilder() then the containing object would be built with a null NestedAutoValueType, even if foo() was not @Nullable. Now it will be built with a default NestedAutoValueType, and if some properties in NestedAutoValueType don't have defaults you will get an exception.

The previous behaviour was that `strings()` could never be null, even if it was @Nullable, because the builder started off with a value of ImmutableList.of(). That seems acceptable and even desirable, since a @Nullable ImmutableList invites confusion as to the difference between an empty list and a null one. So now we forbid having a property builder for a property that is @Nullable, whether a collection or a nested @AutoValue.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148559773