Revisit supported set of kap tables

As part of ensuring that different kap handles can use different opacity tables (so for example, so two stars in a binary can each used different tables), MESA/kap had to know about the possible set of tables that it can use. At present, that means that we manually list the available tables in kap_def. The tables included there were based on what were listed as options in the docs. This is a subset of tables that are actually shipped with MESA. For example, none of the alpha-varying kap tables are explicitly listed. However, one can still use these tables by treating them as user-provided tables. There's still a limitation though, as we only provide one slot for user-provided tables, so one can't currently have two stars with different user-provided custom tables.

The current framework may seem like overkill given that the tables that we ship are all so similar, but the idea was to make it easier to incorporate new tables from OP and/or OPAL.

In the future, likely as part of incorporating new kinds of tables (e.g., #85), we should revisit the kap storage design and the set of tables that we ship with MESA. Seems cleanest if we ship a small set of tables with simple and robust procedures for users to use custom tables. (If we do want to ship larger sets of similar tables, it might be worth redesigning to separate the file prefix and the table format.)

Start by reviewing the MESA/kap code and the manually maintained table list in kap_def, then compare that list with the tables shipped by MESA. Clarify whether the goal is to expand the supported set, redesign table storage, or support multiple custom tables; done should include an agreed design and corresponding user-facing table-selection behavior.

Written by the indexing model from the issue text.