Should the Rules traits be marked UnstableSealed?

[sffc]

I'm unconvinced that these traits definitely have the shape that we will always want. We already found one gap, #6959.

The point of these traits is to make it easier to implement these calendars in userland. Crucially, clients can already do this by implementing the UnstableSealed trait Calendar.

We're not confident about the shape of Calendar, so why should we be any more confident about the shape of Rules?

If we mark these traits as UnstableSealed, it still allows users to implement them in userland, it's just that they commit to the unstable contracts that we already require in other contexts like try_new_unstable.

@robertbastian @Manishearth

[sffc]

Example of some potential future yet-to-be-designed functionality: maybe someone wants to implement Japanese lunisolar with the historic Japanese era names. This should ideally integrate with Date::try_from_fields, but the era names differ from other Chinese-based calendars, which means it needs to be on the trait.

[Manishearth]

I think it's reasonable to mark them UnstableSealed for 2.1 and have a followup for polishing them.

One question: should we doc(hidden) the methods or call them unstable_foo so it's clear that directly calling them is also unstable?

[Manishearth]

We really should implement the "unstable" feature so that the trait can be made private-on-stable-ICU4X.

[sffc]

I think it was a mistake in 2.0 for all the scaffold traits to not have unstable_* method names. I think we should do that moving forward.