Segmenter constructor options/preferences normalization

[sffc]

In #3284 we decided to add a content_locale option to segmenter.

In #5839, @zbraniecki asked some questions about the signature of the constructors.

Currently we have constructors of the following shape:

1. new: singleton static data (infallible), no content locale tailorings
2. try_new_unstable: dynamic data, no content locale tailorings
3. try_new_with_options: static data with content locale tailorings
4. try_new_with_options_unstable: dynamic data with content locale tailorings

Which of the following should we do?

1. Keep all 4 sets of constructors listed above
2. Remove constructor sets 1 and 2. Rename 3 and 4 to not have with_options.
3. Remove constructor set 2. Rename 3 and 4 to not have with_options. Keep constructor 1 as a compiled data infallible optimization.

And, should we take a LanguageIdentifier or a preferences bag for the content locale? (Please understand the discussion in #3284 before stating an opinion on this)

@zbraniecki @makotokato @aethanyc @Manishearth

[aethanyc]

If we were to reduce the number of constructors, I'm leaning toward option 3 to remove constructor set 2. I feel it is not too terrible to ask the user to pass Default::default() as the option to the constructor.

Note: there is probably a naming inconsistency in LineSegmenter. We should prepend try_ to the method name in LineSegmenter::new_auto_with_options, LineSegmenter::new_dictionary_with_options, and LineSegmenter::new_lstm_with_options, because they all take LineBreakOptions which contains content_locale.

[sffc]

@aethanyc I lean toward option 3 a well, but I think we should take the opportunity to give the function ::new() a better name. This is also aligned with the discussion in #5554.

Some ideas:

• new_root
• new_invariant
• new_without_options