Ergonomics improvements for property types

[cmyr]

In the course of using icu_properties I've run into a number of little ergonomics issues that seem like they could be improved:

• mapping between script names and Script instances is unintuitive. I would expect the majority of users are using baked-in data, which means it should be possible to have methods on Script for doing these conversions, like Script::short_name or Script::long_name, or a Script::from_short_name constructor.
• similarly for mapping from a codepoint to a script; when baked data is available, couldn't we just have a Script::for_char constructor?
• alternatively, instead of making me manually name and instantiate types like CodePointMapData, couldn't we have a type method on the relevant type, so that I could call BidiClass::codepoint_map? In the case where this is borrowed static data this could even be available as a const, like BidiClass::CODEPOINT_MAP or something?

In any case these are just a couple ideas, and someone who has spent more time on this project might have better ones.

[Manishearth]

In general I agree. The overall design of ICU4X is to put data loading front and center, however I actually do expect most pure Rust users to just use compiled data, and adding more convenience APIs seems good.

I suspect most disagreement will be from the angle that data loading must be explicit.

[sffc]

I think there are numerous advantages toward making calls through the data structures explicit rather than implicit. However, I'm amenable to convenience constructors that improve discoverability.

For example:

// Current:
PropertyNamesLong::<Script>::new().get(Script::Adlam)
CodePointMapData::<BidiClass>::new().get('🎃')

// Alternative:
Script::long_names().get(Script::Adlam)
BidiClass::code_point_map().get('🎃')

// Also allows for:
Script::long_names_with_buffer_provider(&provider).get(Script::Adlam)
BidiClass::code_point_map_with_buffer_provider(&provider).get('🎃')

[Manishearth]

Currently there is no way to check the value of a binary property over FFI without allocating. This seems like a dealbreaker for ICU4C replacements: most code using iCU4C for "singleton type" APIs will not be persisting some data object and cannot be easily migrated to doing so.

This might also apply to casemapper APIs: I'm looking at the usage of tolower/toupper in bionic as well.

[Manishearth]

Alternatively we can try returning &'static CodePointSetData8 (etc)? I believe Diplomat supports this but it may be buggy. Still suboptimal to go over an FFI call here.

[Manishearth]

No, the duplication with the Borrowed types is going to be a problem here.

[Manishearth]

I'm going to file two related issues: one to add convenience methods here as per my plan, and one to talk about the broader problem of ffi singletons.

[Manishearth]

Issue for enum props: #6049

Issue that covers the broader problem including binary props: #6050