Core: Allow common collections in OptionSet and OptionList constructors

[Jouramie]

What is this fixing or adding?

Allow for usage of set, list, frozenset and tuple in .from_any(data) factory methods of OptionSet and OptionList.

I needed to add tuple support specifically to OptionSet, to use the .from_any(data) to parse the options, specifically the Mods combinations generated with itertools.combination().

Currently, if OptionSet.from_any(...) is called with a tuple, it is stringnified. For instance, that causes the tuple ("DeepWoods", "Tractor Mod") to be transformed into '("DeepWoods", "Tractor Mod")', which is then split on the , to create the OptionSet with the values '("DeepWoods"' and ' "Tractor Mod")', which are very obviously invalid. To add more to the issue, the validation is not even called because it fallbacks on the .from_text(...) factory method. This issue went unnoticed for weeks in our dev branch.

I could have changed the tuple to a set in each test, but it seems much simpler if the core supports it. Parsing and validation issues are solved at once.

One of the tests in question, FYI

    def test_given_mod_pairs_when_generate_then_basic_checks(self):
        if self.skip_long_tests:
            return
        for mod_pair in itertools.combinations(mod_data.all_mods, 2):
            world_options = {
                Mods: set(mod_pair)
            }
            with self.solo_world_sub_test(f"Mods: {mod_pair}", world_options, world_caching=False) as (multiworld, _):
                self.assert_basic_checks(multiworld)
                self.assert_stray_mod_items(mod_pair, multiworld)

Even if this technically adds an explicit dependency on typing-extensions, it was already a transitive dependency of Flask-Limiter, so it's not really a new dependency.

How was this tested?

Ran the tests, generated a plando seed with Stardew and Dark Souls III, plus generated a seed with all currently supported game (default options).

Honestly, those types are not even used with Generate.py, so I have big doubts it actually changes anything for generation in general, beside the insignificant performance drop from changing type(data) == list to isinstance.

If this makes graphical changes, please attach screenshots.

No graphical changes

[agilbert1412]

Code looks good, idea seems reasonable

[beauxq]

@Jouramie Jouramie#1

[beauxq]

I looked over all of these changes with linting and type checking and thinking about the logic, and it looks good.

[black-sliver]

Besides typing, basically only changes an isinstance() and adds a list() and those seem to be correct.seems to be correct.

[beauxq]

I should have noticed this. You changed the type var from Any to str, and I trusted it.

[black-sliver]

I missed it as well. We can at least partially blame the lack of unit tests :-)

[Jouramie]

Well, I should have checked deeper how this was used. Definitely my bad on this one.