Add Quality item sorting + major item sorting refactor

[SSM240]

In a recent update to Quality, they added the feature to group together different quality versions of the same item. However, it ends up not doing that much if you have stack count sorting on from this mod.

So I was like, fuck it, let's just do it myself, and then also go further, because I apparently can't get enough of item sorting.

First off, to make it more easily extensible, I completely rewrote the SortItems method. Instead of worrying about separate lists for tiers and scrap and all that, or trying to shove all our sorting criteria into a single number, I just use a tuple instead. This is a much cleaner way of sorting based on several different criteria with different priorities - the stuff we want to separate out goes first, and the stuff we want to keep grouped together goes at the end. And since the sort is stable, we can just disable a given sorting criterion by setting its key to 0.

(While I was at it, I changed SortPickups (used for the Chef crafting interface) to simply defer to SortItems instead of duplicating logic, and made it consistently match scrapper sort settings. except I didn't implement the alphabetical sorting because I could not be assed lol, someone else can probably figure that out if it's deemed important)

All that was to more easily support the main feature, which adds two settings:

• Sort Quality Items: Has three main modes. "Grouped" acts similar to the setting from the main mod, and groups together every version of the same item. "Separated" instead treats each quality as something like a sub-tier, and groups together all quality items of a given tier instead. "Off" disables the feature entirely and makes it act like before (except quality consumed regen scrap, that's always considered scrap for consistency).
• Quality Items Order: Whether qualities should be sorted in ascending (common to rare) order, descending (rare to common) order, or not reordered at all.

On a technical level, this involved adding a soft dependency + assembly reference for the ItemQualities mod. The important notes regarding the compat are:

• As per the wiki, the most important thing for soft dependencies is to ensure that all references to the other mod's types are in their own methods, and that said methods are only ever called when the mod is loaded, which is sufficient to prevent errors when the mod isn't loaded. The NoInlining and NoOptimization flags help with this, by stopping the runtime from being too greedy and potentially accessing the method bodies without them being called.
• I opted to include a stripped version of the DLL in the repo. This means people don't need to provide their own versions just to build the mod, but it does mean the reference might need to be updated if there are any breaking changes to ItemQualities. I used NStrip to strip the mod DLL, though stripping isn't strictly necessary, just nice for keeping filesize down. I did avoid publicizing it though, just because sticking to its public API is almost certainly more resilient to future updates.
• Putting everything in its own class isn't strictly necessary, but I did want to limit the scope of the usings so you're not getting autocomplete for ItemQualities everywhere else.

Miscellaneous details / concerns:

• The acquiredOrder dict might seem dumb at first, since they're already ordered that way by default, but it's necessary for quality grouping while otherwise maintaining acquisition order, since I need to access other items' positions in the inventory. (Technically you don't need it, but searching an array is O(n), and doing that for every single item sounds probably bad.)
• Actually, speaking of performance, I'm not 100% sure in general. I tried to avoid obvious performance blunders but I haven't done any proper benchmarking. I'd guess it's probably fine (I didn't notice any issues while playing, though my PC is pretty good), but it still feels like we're doing quite a bit of work for every item in the inventory. Maybe it's not a big deal since this stuff only runs when the inventory is updated.
• Maybe HandleQualityItems could be handled better? It does need to be its own method, but I will admit taking a billion parameters, some of them ref, is a bit ugly. I just felt like it was most straightforward to treat it as "part of" SortItems, just separated out for technical reasons. (I guess it could be another nested local function to avoid having to pass all that state, but that also feels ugly + not having it in its own file means you run into the usings problem I mentioned.)
• Should there be more sorting priority options now? I could see there being a demand for it (e.g. some people might want to group all quality items of all tiers together, separately from normal items) and the new system would be easier to implement that for. I'm not certain it's the best idea, though - having too many different sorting options feels like bad UX, and making the priority list fully customizable doesn't feel much better. I think it's probably fine to treat this as "we can worry about it if anyone cares enough to ask about it."
• If Quality ever adds its own dependency on LookingGlass (e.g. to implement their own item stats) we might run into circular dependency issues... I feel like that's another "we'll worry about it if it happens" situation though.
• When Quality isn't installed, would it be a better approach to simply disable the settings in the menu instead of hiding them altogether? I think it's better to not expose cross-mod compat when it's not relevant (feels kinda like advertising the mod to people who may not care), but having some settings just not show up at all sometimes feels potentially confusing. I could go either way on this one.
• Probably some other shit I'm forgetting, if you have any more questions/concerns/nitpicks please say so. I did do a decent amount of testing to make sure sorting behaves as expected with most combinations of settings (including when Quality is both enabled and disabled), but I'm not 100% certain I haven't missed some funky edge case. I do plan on doing more testing via playing with this version in my casual runs, so there's no rush to merge this ASAP, but I wanted to put this PR up while everything is still fresh in my mind.

[SSM240]

Well I've done a decent few runs with this version now, and aside from the bug I just fixed (modded items were accidentally being sorted like an uncommon quality because I used the wrong default), I haven't found any problems with sorting or errors in the log, so I'm reasonably certain it's stable. Can probably be merged unless you have any major concerns.

(also, the force push was just cus i wanted to add a quick code comment without making a new commit, but it turns out doing that also shows up here lol)

[ToastedOven]

Sorry, I forgot to merge this forever ago. That's my bad