Formatting era index is really bad and will break in CLDR 48

[sffc]

We should try to avoid shipping ICU4X code that we know will break in the next CLDR release.

CLDR will be changing the AH era to be index 1 instead of index 0 in the next release:

unicode-org/cldr#4581

This means that mismatched code and data will result in differing results, results that will be outright wrong. Not just unintelligible, but wrong. I noticed this in #6443

To fix this, I suggest making era index 0 be the primary era (all calendars using era indexes have a primary era) and index 1 the secondary era.

Except that might not work in Ethiopian... maybe just special-case Ethiopian?

@robertbastian @Manishearth

[Manishearth]

Yeah this was partly why I was hesitant to make our era indices data driven.

I do think we can still patch this up in datagen if we wish.

I'm fine with index 0 being the primary era where there is one (with Ethiopian being an exception). Is CLDR consistent about this? If not then we lose consistency with CLDR.

[sffc]

I see no value in having consistency with the CLDR era types.

I think we should fix this and do 0 = primary, 1 = secondary, and for Ethiopian 0 = amete alem (since both calendars have it) and 1 = amete mihret.

I don't think we need to wait on CLDR to move. I think we can just do this.

[Manishearth]

It was a deliberate choice made in #6252 . Robert didn't like that we hardcoded an era map. I'm not a fan of the data driven model either but I think it's fine, this issue is a good reason to undo those changes.

[robertbastian]

I'm hesitant to change from Option<u8> to Option<bool>. The former works just fine, and we would paint ourselves into a corner if we ever needed to support a third era.

[sffc]

Not fixed: the indices are not fixed