Improve loadout handling on schema changes

[nosoop]

CanPlayerEquipItem(), the function that is handled for item access, is only checked when the player selects the item.

If the player already has an item selected for their loadout, they are still allowed to equip it even if the access changes on either the item or the player (or if the item isn't valid for that class anymore, but #19 covers that case).

We should also gracefully handle removals of items from the schema.

I think most of this could be resolved by simply resetting loadout entries that the player is incapable of using back to default (and submitting those changes to the backend). Might be good to log those events as well.

[nosoop]

Okay; now I remember — the problem is that an item's availability may be indeterminate in the future. One of the ideas for the API (coming out someday™) was to allow importing items from KeyValues handles on-demand to allow for item definitions stored remotely, so the player may have an item that the plugin is not aware of.

The current design doesn't have a good UX for this.

How do we handle "possibly available" items in menus? The player won't have their default item selected, nor will they be able to see their item in the menu. They won't be able to select the item again if they change to something else. We could reset it to the default item for the current session (without updating the backend), but that may be confusing.

[nosoop]

One solution would be to "locally" cache imported remote entries as a UID / KeyValue string pair. That way, items are always available once they've been seen, and player loadouts would always be valid — item imports would really just be inserts / replaces within that database.

Some special handling would be in place for locally-defined items, of course.