Two bug fixes in map field binary parsing

[osa1]

Map fields are encoded as repeated message fields where the message
field 1 is the key and 2 is the value.

In proto syntax, a map field like

map<int32, MyMessage> map_field = 1;

is encoded as if it was

repeated MapFieldEntry map_field = 1;

where

message MapFieldEntry {
    optional int32 key = 1;
    optional MyMessage value = 2;
}

Since map entries are ordinary messages, it's possible for a map entry
to have no key or value fields.

This PR updates map decoding to handle missing key and value fields.
Three tests added for (1) missing key field (2) missing value field (3)
missing key and value fields (entry message has 0 length prefix).

Fixes #719

[sigurdm]

LGTM

[osa1]

I just realized that proto2 and proto3 specs give different encodings for map fields:

map<int32, MyMessage> my_messages = 1;

===>

repeated MyMessagesEntry my_messages = 1;

// According to proto2 spec
message MyMessagesEntry {
    optional int32 key = 1;
    optional MyMessage value = 2;
}

// According to proto3 spec
message MyMessagesEntry {
    int32 key = 1;
    MyMessage value = 2;
}

These two encodings are not the same, for example, if a value fields is missing, proto2 implementation might return "null" for the value, while a proto3 implementation needs to return the default value for the message (which may or may not be null).

So I'm not sure if this PR is correct. I'll try get proto team's opinion on this.

[osa1]

I asked about this to protobuf team. The key point is {key: 0, value: {}} should be identical to {} after the parse step. So we should handle missing key and value fields as we handle missing fields in messages that are not map entries.

I will merge this PR after testing internally.