Merged as part of b/207106531

This is inspired from b/205606725 and older b/111967450 where MX stopped supporting all additional dialling codes.

* [maven-release-plugin] prepare release v8.12.37

* [maven-release-plugin] prepare for next development iteration

It is being a maintainace issue to keep updating JS api to be compatible with newer closure releases.
https://buganizer.corp.google.com/issues/192369473

* [maven-release-plugin] prepare release v8.12.36

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.35

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.34

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.33

* [maven-release-plugin] prepare for next development iteration

- This change is only for some metadata/ apis only.
- Bumped up java version for this.
More details in cl/396604897

* Update FAQ about "why parsed national number is different in JS".

Inspired from https://issuetracker.google.com/issues/198423548

* Update FAQ.md

- When configured "pull_request[type: opened] + push", workflow not getting triggered when there is a change in PR code/commits when the branch is from the parent's forked repo.
- Configured only pull_request event as any change can only go through PR. 
- pull_request event by default happens when opened, synchronize (means whenever there is change/commit, sync happens), and reopened. So this should be good enough for our use cases.

More details in [approach doc](https://docs.google.com/document/d/1YNYUAlEUXTi4UZG5gEFZGQ7oe7LxNKh7FYSg2qtIUvI/edit#heading=h.1c7qt5y1jb9)

Our objective is to (replicating the previous setup):
- Do Maven test of LPN tool modules common, data and java-build through a Maven profile.
- Also build and test run ant target “junit” that unit tests the java LPN  api jar after being built.
- Check whether LPN’s JS API/files are in ascii format/not. 
- More details are mentioned in [approach doc](https://docs.google.com/document/d/1YNYUAlEUXTi4UZG5gEFZGQ7oe7LxNKh7FYSg2qtIUvI/edit)

* [maven-release-plugin] prepare release v8.12.31

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.30

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.29

* [maven-release-plugin] prepare for next development iteration

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

* [maven-release-plugin] prepare release v8.12.28

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.27

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.26

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.25

* [maven-release-plugin] prepare for next development iteration