refactor team loadout data structures in preparation for lifting the ship class limit

[Goober5000]

team_data was the last persistence-adjacent structure sized by MAX_SHIP_CLASSES: four parallel ship arrays plus four parallel weapon arrays (one slot per mission-file loadout line, holding a class or a sexp variable name, and a count or a sexp variable name) with manual num_*_choices counters, plus a dense per-class weapon_required flag array. Convert all of it to the sparse-container family:

ship_list / ship_list_variables / ship_count / ship_count_variables
-> SCP_vector<loadout_entry> ship_choices
weaponry_pool / weaponry_count / weaponry_pool_variable /
weaponry_amount_variable
-> SCP_vector<loadout_entry> weapon_choices
bool weapon_required[MAX_WEAPON_TYPES]
-> SCP_set required_weapons

where loadout_entry is {class_index, count, class_variable, count_variable}, with empty variable strings meaning the value was given literally. num_ship_choices / num_weapon_choices become .size().

Intentional behavior fixes, all previously latent memory errors or
data bugs:

• is_ship_assignable stored an alt ship CLASS in a variable used as a
  loadout list INDEX when default_to_this_class was false, then
  swapped to ship_list[class] - garbage for any mission where the two
  domains diverge. It now swaps to the alt class itself, per the
  evident intent.

• The default-ship fallback read ship_list[0] even when a team had
  zero ship choices; it now leaves default_ship at -1, and
  ss_fixup_team_data guards its append of the default ship accordingly.

• FRED2's dumpstats indexed Ships[] with a ship class when printing
  loadout entries; it now prints the entry's class or variable name
  directly.

• Team parse now clears the previous mission's entries explicitly
  rather than relying on overwrite-in-place.

This clears the largest remaining cluster of MAX_SHIP_CLASSES references on the way to lifting the ship class limit.