Handle <alias> nodes

[movermeyer]

The root locale contains <alias> elements that tell the reader that they should restart their search with a different key.

Example resolution

For example, resolving //ldml/dates/fields/field[@type="hour-narrow"]/relative[@type=0] for en_GB in CLDR v34 (for example) should look at:

• //ldml/dates/fields/field[@type="hour-narrow"]/relative[@type=0] in common/main/en_GB.xml
• //ldml/dates/fields/field[@type="hour-narrow"]/relative[@type=0] in common/main/en_001.xml
• //ldml/dates/fields/field[@type="hour-narrow"]/relative[@type=0] in common/main/en.xml

Before finally //ldml/dates/fields/field[@type="hour-narrow"]/relative[@type=0] in common/main/root.xml, where it finds the alias:

<field type="hour-narrow">
  <alias source="locale" path="../field[@type='hour-short']">
</field>

And restarts the search using hour-short, which in turn leads to another alias, restarting the search using hour, which is eventually resolves to:

this hour from //ldml/dates/fields/field[@type="hour"]/relative[@type=0] in common/main/en.xml.

Steps to reproduce

thor cldr:export --locales 'en' 'en_GB' --components Fields --merge

• I expected data/en-GB.yml to contain a en-GB.fields.hour-narrow.relative.0 key with the value of this hour
• I expected data/en.yml to contain a en.fields.hour-narrow.relative.0 key with the value of this hour

Once exported, there is no information in the exported YAML files about aliases.
This means that a client cannot know to use the en-GB.fields.hour.relative.0 key instead (for en-GB), which exists.

(Aside: this example uses --merge, but it equally applies to the non-merged case. I used the --merge case for simplicity)

Impact of this issue

Data exports are incomplete. Any aliased field is missing a corresponding value in the exported files.
The above hour-narrow example is not that impactful (clients lose access to the hour-narrow format 🤷).

In other cases, <alias> elements are used for more impactful values. For example, the Buddhist calendar data are largely aliased to Gregorian calendar data.
While ruby-cldr doesn't currently export Buddhist calendar information, if it were to, it's lack of <alias> handling would mean that the Buddhist calendar would be missing most of its data entirely.

Another example: The symbols for many numbering systems are aliased to the Latin number symbols. Without resolving the aliases, the symbols are not present in the exported data (Actually, they are, but that's due to another bug).

Potential Solution

Output aliases in the manner supported by ruby-i18n/i18n's Symbol resolving.

If --merge flag is used, resolve the value and output that instead.

[movermeyer]

Another example:

The root locale contains <alias> nodes for calendar eras:

• dates/calendars/calendar[8]/eras/eraNames/*
• dates/calendars/calendar[8]/eras/eraNarrow/*

These are incorrectly getting output as:

eras:
  abbr:
    0: BCE
    1: CE
  name:
    0: ''
  narrow:
    0: ''