* Make canBeInternationallyDialled_API public in Java and CPP
* update notes in pending_code_changes.txt
* Remove TODO on canBeInternationallyDialled as it is already an public API in JS
* Make JS canBeInternationallyDialled API doc consistent with Java and CPP

1) Changing the BuildMetadataFromXml to only set
same_mobile_and_fixed_line_pattern and
national_prefix_optional_when_formatting if they differ from default
values, and the domestic_carrier_code_formatting_rule,
international_prefix and national_prefix_formatting_rule if there is
one.

2) Adding a test with some golden data for the BuildMetadataJsonFromXml.

3) Adding to the proto a missing explicit default false.

4) Updating a couple of methods in the Phonemetadata.java class to have
names that match those of the auto-generated Phonemetadata used by the
CPP build, now that we use those methods when building the metadata.

5) Fix to ant build file to enable the junit command to still work (instructions on open-source on how to regenerate metadata files refer to this)

Resulting data is smaller for Java and C++ and the resulting BuildMetadataJsonFromXml code is cleaner.

This excludes editing the proto file itself, or the auto-generated or hand-crafted fields that are derived from it.

Metadata changes:
-- Drops the "-1" that was erroneously included in possible lengths before (didn't break anything, but was wrong) - it was a possibleLength of a sub-component so got added to the generalDesc possibleLengths
-- possibleNumberPattern no longer inherited: we don't use this anyway, we will do another CL soon to stop including it at all in the generated metadata
-- exampleNumber is no longer set on fixed-line and mobile elements from the generalDesc

XML file changes:
-- Stopped specifying "NA" and "-1" specifically for fixed-line and mobile blocks; now they are treated as every other type of phone number: if missing, don't fill them in from generalDesc, but leave them missing.

Code changes:
-- Stop using the exampleNumber on generalDesc for non-geo entities, but look at their phonenumber descs - the exampleNumber won't be stored on the generalDesc anymore. This affects porters if they either copied our build logic or used our built metadata in some way; they should update this method in their port too.

- Handling language codes that are not just two-letters long appropriately
- Making file processing deterministic, so this doesn't differ from build to build

We remove the dependency on protobuf (protobuf-javanano) from the Java library, resurrecting java/libphonenumber/src/com/google/i18n/phonenumbers/Phonemetadata.java which was present until libphonenumber-7.1.1.

Does not affect the C++ or JavaScript libraries.

https://groups.google.com/forum/#!topic/libphonenumber-discuss/75TOpTFVi08

* Initial code changes to support the new possibleLengths infrastructure
when building metadata. Includes setting these in the main metadata
file and changing the code to populate them in the PhoneMetadata proto
at build time. Updating tests for Java.

* Updating comment about the possible_lengths_local_only field.

* Adding the generated jars that build files containing the new possible
lengths fields.

* Rebuilding short-number metadata with the new proto field. Not doing
this at release time so we can see what changes in the metadata are due
to metadata fixes, rather than this possibleLengths field.

* Regeneration of phone number metadata with the new possible length
information filled in.

Includes some possible length changes for KR and BY, and a validation
fix for NA where a digit was missing.

* Updating the test proto metadata files with the new possible length
information.

* Added notes about the code changes.

* Regenerating C++ metadata with new possibleLength info and updating unit
test to check this works.

MultiFileMetadataSourceImpl.

No change in functionality.