Null message fields should not be instantiated

Given, for example, the following proto definitions:

```
message Address {
string street = 1;
}

message User {
Address address = 1;
}
```

the current behavior, when decoding an incoming User message, is to initialize the Address generated class even if the field is unset, filling it with empty ( zero ) values, which should not happen.

This is crucial for a variety of situations, for example using [value wrappers](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/wrappers.proto), which are [Protobuf Well-Known Types](https://developers.google.com/protocol-buffers/docs/reference/google.protobuf) and represents the Google solutions to distinct a scalar field zero value from its default value. This is actually not possible with the current dart implementation, because the wrapper generated class is instantiated anyway and the inner value becomes a zero value.

Also, I think this is what was referred in #245.

Start by reproducing the issue with the provided User and Address proto definitions and inspect the generated Dart decoding behavior for the unset address field. Compare this with protobuf value-wrapper usage; done means an absent message field remains uninstantiated while explicitly present fields still decode correctly.

Written by the indexing model from the issue text.