feat(ivy): ICU support for Ivy (compiler side)

[AndrewKushnir]

The goal of this PR is to add I18n ICU support to IVY compiler. In order to satisfy the backwards (and forward) compatibility requirement, the logic of producing translation messages (goog.getMsg at this moment) mimics existing ng xi18n machinery output, specifically:

• each ICU takes a separate translation call/unit
• nested ICUs are not presented as top-level translations, they remain a part of the parent ICU
• attribute translation also takes a separate call/unit

The I18n AST (which is used to power ng xi18n mechanics) was employed to minimize discrepancies between the ng xi18n output and IVY compiler output. Nodes within I18n sections now have references to their canonical representation in i18n AST, which helps maintain output consistency.

Update (11/8)
As a part of this PR, the following logic was implemented:

• post-processing for goog.getMsg output, since the placeholders might not be unique (for ex. CLOSE_TAG_DIV can be used multiple times, but we have to have different references/indices). Right now in such cases we put a specially-formatted string that contains these combinations (for ex. [�/#1�|�/#4:3�|�7:4�]). The post-processing step assembles the final string at runtime, based on this information.
• the ConstanlPool was refactored and all i18n-related code was moved away
• added support for translations without root element (e.g. <ng-container i18n>)
• added support for <ng-template i18n>
• support for goog.getMsg was improved to generate compatible translation strings and respective placeholders in appropriate format
• implemented i18n self-closing instruction (in case there are no elements between i18nStart and i18nEnd)

This PR now completes the main set of features required for i18n compiler.

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)

Does this PR introduce a breaking change?

• Yes
• No

[mhevery]

I would like @alxhub to have a look at the compiler details as he is more familiar with it. Left comments on the generated code.

[ocombe]

A few things to change, see my inline comments.
And check with @mhevery if we should apply the whitespace removal, and also if we should keep empty translations or not.

[AndrewKushnir]

@ocombe @mhevery thanks for the initial review!
I've addressed your comments (and added some additional features). I plan to add extra tests and docs for utils functions, but generally this PR is ready for another review, when you get a chance.
Thank you.

[alxhub]

First round of comments.

In general, I notice that <element>.i18n ! happens a lot - we're constantly asserting in this PR that i18n fields are not null. I think this indicates a more fundamental issue with the typings. Can you think of any way to avoid this? I've not really studied the problem deeply but I do have one observation which might be helpful.

Part of the problem comes up at the boundary between i18n-processing code and the larger TemplateDefinitionBuilder. We do things like:

if (element.i18n) {
 // i18n field is known to be defined here.
 doSomethingWithElement(element);
}

function doSomethingWithElement(element: t.Element) {
  // element.i18n is not known to be defined, so assertion is required.
  console.log(element.i18n !);
}

Instead of this pattern, we could make functions on the boundary to which i18n-enabled nodes are passed have signatures like:

function doSomethingWithElement(element: t.Element & {i18n: I18nType})

This way:

1. we can only call the function on a t.Element with a valid i18n field.
2. we don't lose that information in the body of the function, and thus don't need the assertion.

This gets the type system working with us and not against us.

Make sense?

[googlebot]

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

[mary-poppins]

You can preview a1bb4be at https://pr26794-a1bb4be.ngbuilds.io/.

[AndrewKushnir]

@alxhub thanks for review!
I rebased this PR from the latest master that now includes the change from a different PR (60800da), which takes care of elementContainer-related changes (so my PR no longer contains this code). Thank you.

[AndrewKushnir]

New g3 presubmit: https://test.corp.google.com/ui#id=OCL:221834624:BASE:221845278:1542404421436:6da2e0dc

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}