The PhoneMetadata class that's included is a mix of v1 and v2 APIs and will be
changed over time to only support the v2 API.

* Hungary, remove special code to add national prefix

* Porting same changes to JS

* Abolish MX's international mobile token

* Porting phoneutil changes to JS and AYTF changes to not to swallow parts that are not part of formatting rule.

* Make fake change to trigger travis build again

* Adding checking of leading digits before using an alternate format rule
when finding phone numbers in text (previously we thought this was done, hence why the data was there, but it wasn't).

Also some minor comment/formatting changes, and splitting a private helper method
into two.

The format of the data has changed such that formatting patterns now only refer to \d, not specific numbers, so we don't need the special handling in the AYTF code which converts them to \d.

* Fixing brittle unit test of checking example short number

* Making same changes in CPP and Java

Updating AsYouTypeFormatter for better format selection for numbers dialled domestically

* Update ShortNumberInfo test regarding example number change for region AM. Unlike PhoneNumberUtilTest, ShortNumberInfoTest uses real metadata for unit testing.

* Changing the region as Travis tests do not pass with old short metadata of AM

* Making same changes in CPP and JS

* Cleanup in continuation to support to russian extension characters

* Nit: \xBE (uppercase E) for consistency

* Configure Russian extension character доб as a valid one while parsing the numbers

* Escaping non ascii characters for better standardization.

* Added generated RU test data file. This is why travis test are failing at: https://travis-ci.org/googlei18n/libphonenumber/builds/407078226

* Removing manual support of encoded versions as it is already taken care in RegEx flags. Updated based on new review comments.

* Update formatForMobileDialling() to return E.164 format instead of national format for Uzbek phone numbers.

* Update java doc to be more clear

This hasn't been used for a long time.
Deleted all methods that refer to this, and removed the field from the test XML file (somehow this was missed) as well.
Regenerated jars - because we no longer write a boolean to indicate whether we have the possible number pattern or not all the java metadata files needed regenerating too.
Deleted some data from the js phone metadata implementation that isn't used by js as well (national number matcher pattern)

This enum won't be noticed by most users, because the country_code_source field of the phone number is only populated with ParseAndKeepRawInput, and in this case, this enum won't be used.

However, it provides a better result for users who incorrectly call parse() and then getCountryCodeSource() and expect to get a sensible answer; now they will get UNSPECIFIED instead of FROM_NUMBER_WITH_PLUS_SIGN which was the default before. In JS this method returns null, but getCountryCodeSourceOrDefault() will now return UNSPECIFIED instead.

The numeric values of the existing enums have not changed (relevant for JS and C++) and in Java the new enum was added to the end so that any stored serialized phone numbers should be able to be restored as they were before.

Suggested in issue #1218

*   It was confusing and unnecessary. Not every country that has short numbers beginning with a 0 had it, and it is not the only digit that could overlap with a national prefix and hence be interpreted incorrectly.

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.

* Handling possible out-of-bounds exception that would be thrown in C++
and Java if a number with a phone-context tag is entered (RFC3966
format) but no actual phone context.

IS_POSSIBLE_LOCAL_ONLY and INVALID_LENGTH are now being returned from IsPossibleNumberWithReason.

The enums were added in v8.3.0

Groups announcement: https://groups.google.com/forum/#!topic/libphonenumber-discuss/sPhYzdzFCmg

Fix for getNationalSignificantNumber to be robust in the face of malicious input (negative number of leading zeros in the phone number proto).

* isNumberMatch fix for numbers with italian leading zero fields set. Only
affects people who haven't correctly constructed phone numbers using
methods like 'parse'.
* Adding C++ tests and fixing bug in ExactlySameAs method, which wasn't
updated to handle the number_of_leading_zeros field when that was added
to the phone number proto.

See pending_code_changes.txt for more details.

* Support semicolon as extension character while parsing

* Add notes to pending_code_changes.txt

* JS port: Support semicolon as extension character while parsing

* Update comments in phonenumberutil.js

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.

Changing PhoneNumberUtil to use the possibleLengths information, not the reg-exes.

Note the API is not changing, but the metadata is now somewhat stricter for
many countries, since before we applied only a minimum and maximum length for
most countries, and now we specify exactly which lengths are possible.

This has a flow-on effect when parsing, since we decide whether to do certain
operations like strip a national prefix based on whether the number is a
possible length before/after - when parsing, if the number is shorter than the *national* pattern, we no longer strip the national prefix.

Affected countries:
AD (7 digits now invalid)
AM (7 digits now invalid)
AR (9 digits now invalid)
AZ (8 digits now invalid)
BG (4 digits now valid for local-only numbers)
BJ (5-7 digits now invalid)
CC/CX (5 digit numbers now possible: this should always have been the case, but the generalDesc was wrong and didn't reflect its child elements. We now calculate it based on them, which allows 5 digit numbers.)
CO (9 digits now invalid)
CR (9 digits now invalid)
ET (8 digits now invalid)
GE (7 and 8 digits now invalid)
GH (8 digits now invalid)
IL (5 and 6 digits now invalid)
IM/JE/GG (7, 8 and 9 digits now invalid, shortest national number length now 10, so parsing affected for numbers shorter than this)
IS (8 digits now invalid)
KG (7,8 digits now invalid)
KR (11 digits now invalid)
LA (7 digits now invalid)
LI (8 digits now invalid)
LY (8 digits now invalid)
MV (8 and 9 digits now invalid)
MW (8 digits now invalid)
MX (9 digits now invalid)
NP (9 digits now invalid)
SE (11 digits now invalid)
SG (9 digits now invalid)
SL (7 digits now invalid)
SM (7-9 digits now invalid)
UA (8 digits now invalid)
UG (8 digits now invalid)
UZ (8 digits now invalid)

- LOGGER -> logger
- Small comment fixes
- Style-guide-recommended formatting changes
- Removal of duplicate, unneeded method in PhoneNumberToTimeZonesMapper.java for canBeGeocoded, using phoneNumberUtil instead.

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.

Making function IsNumberGeographical public. This function operates on
the type of number and the country it belongs to only, so may have some
false positives.

Using this in the geocoder so that geocoding now limited to numbers that
we consider geographical, based on their type and country, rather than
just based on their type. The C++ geocoder did not previously check the
number type/country at all.

Indonesian and Chinese mobile numbers have now been added to the list of
possibly-geographical numbers.