- Faced link errors stemmed from mismatch of api definitions of absl::node_hash_set. So explicitly mentioned this lib as dependency during linking. This is common case/solution for absl hash set lib's link errors as per community.
- Decided to continued to have wrapper (stringutil), so that in future it's easy if we decided to change implementation; client code is safe. Changed most of the implementations & data structures in stringutil, to use abseil stuffs more.
- Though absl::string_view is suitable for most cases where we want immutable/read-only string structures, limiting to stringutil apis, not changing public API signatures (even though no compliance issue); reason: reduce dependency on abseil libs.
- Abseil specific changes done:
    - std::set => absl::node_hash_set
    - std::map => absl::node_hash_map
    - Using absl alternatives for “SplitStringUsing” API and “StringHolder” class impl.
    - Replaced manual impl of prefix and suffix checks with absl::StartsWith() and absl::EndsWith.
    - Similarly used absl::StrReplaceAll, absl::StrCat, absl::StrAppend where possible; and for type conversion apis.
- Note: Tried applying parameter packs to replace manually written duplicate ```StrCat``` apis (for accommodating more number of parameters of same type), but it did not go well when different type arguments passed. Eg char, int types to be converted to StringHolder; faced constructor implicit conversion issues.

Keep track of whether unicode strings were created from valid UTF-8 and
use this to abort operations that use these strings later.

Typically, this is done by returning an empty string when a modified
string is being produced, since an empty string is never a valid phone
number.

@API updates:
- Migrating from associative containers to more performant types. Eg: map to absl::btree_map.
- Synchronise the write access to map "AreaCodeMaps" using absl::Mutex locking api.
- Use more of absl:strings packages like absl::StrReplaceAll

@Build updates:
- To build (CMake) against absl packages, the minimum version of compiler is CPP11+, whereas earlier we are not mandating this.
- We are upgrading CMAKE version also to automate building the external absl packages.

The change is announced. Please report issues in case of any breakages.
https://issuetracker.google.com/issues?q=componentid:192347%20555

Earlier, AYTF is adding additional CC when returning unformatted result - for cases where the input digits are dropped for formatting. Eg: MX case: "+5213314010666" => "+52 +5213314010666". b/183053929

Now we. are proactively ensuring that no formatting is applied, where a format is chosen that would otherwise have led to some digits being dropped.

Why the input digits are dropped:
- In MX, the mobile token (1) is no more used, so when it is present in input, the formatted result should not contain it.
- However when AYTF, we should not be removing the input digits on the fly.
- More details in cl/373115460 and b/183053929

* Java and CPP port fixes.

* Js port update and added code changes notes.

* Updated text in code changes comments file.

In visual studio 2019 x64 target, size_t are 64 bits and int are 32 bits

Removing unused var, indent fix.

* 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

* Defensive check added to FormatInOriginalFormat

Add a check that the FG is indeed in the national prefix before erasing it, in FormatInOriginalFormat. Matches java interpretation. It should always be there but if for some reason someone generates metadata with it not there we don't want to seg fault.

* Update phonenumberutil.cc

* 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

*   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.

* 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.

vars in the phonenumbermatcher and phonenumberutil that were there to
work around this restriction.

* 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

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.

* Porting code to use the new possible length information for calculating
whether a phone number is possible, too short etc.

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.

* New useful getExampleNumber methods (for testing) - one for invalid
  numbers and one for getting a number of a particular type without
  specifying a country.

Review URL: https://codereview.appspot.com/96510044