JS: parse (un)packed fields conditionally

[qnighy]

The current JS implementation doesn't comply with the following criteria:

Note that although there's usually no reason to encode more than one key-value pair for a packed repeated field, encoders must be prepared to accept multiple key-value pairs. In this case, the payloads should be concatenated. Each pair must contain a whole number of elements.
https://developers.google.com/protocol-buffers/docs/encoding#packed

Protocol buffer parsers must be able to parse repeated fields that were compiled as packed as if they were not packed, and vice versa. This permits adding [packed=true] to existing fields in a forward- and backward-compatible way.

https://developers.google.com/protocol-buffers/docs/encoding#packed

In this PR, the parser checks WireType before parsing packable fields, and then always append to the existing array, instead of replacing it.

Fixes #1701.

[qnighy]

@TeBoring

[qnighy]

@TeBoring I removed the relevant lines from conformance/failure_list_js.txt to enable conformance tests. Is this enough?

[qnighy]

@TeBoring we're occasionally hit by this problem (since our JavaScript client communicates with Ruby servers, where the current implementation always encodes repeated fields unpacked). It's great if you have time to look at this.

[qnighy]

@haberman sorry for the sudden mention, but could you or someone else look at this? The diff is essentially about 30 lines and it should be relatively easy to review...

We're actively applying changes to our internal protobuf messages which are sent between JS and Ruby, and #1701 is a real annoyance since failing to add [packed = false] to a newly defined repeated scalar field ruins everything.

[izumin5210]

@haberman @TeBoring @dlj-NaN can you help to review?

[qnighy]

@haberman thanks for reviewing and kicking the CI! The only failures are Java things (which I think is unrelated to this PR) and the lack of language label (which I cannot help), so I guess there's nothing I can do now. Right?

[qnighy]

@haberman could you merge this?

[perezd]

Thank you for your contributions!