LULC selection menus should reflect parameterized LULC types

[davemfish]

Right now the options in these menus reflect the existing LULC categories that are present in the raster. This is not ideal for two reasons.

1. It could exclude some logical categories that a user might want to create during a scenario. For example, pairing "high" tree canopy cover with LULC types that don't have that pairing in the baseline raster.
2. It could include some combinations of categories that are illogical, because of inaccuracies in the underlying LULC.

If these menus are based on the LULC categories that we have taken the time to parameterize, presumably it solves both of these problems.

[davemfish]

This is on hold until #121 , because the sample parameter tables we have now include placeholder parameters for all possible LULC types, including ones that don't exist in the raster, and including ones that are illogical.

[davemfish]

After parameterization, a separate task should be to label some lucodes as off-limits, so we can hide them from the user.

[davemfish]

1. It could exclude some logical categories that a user might want to create during a scenario. For example, pairing "high" tree canopy cover with LULC types that don't have that pairing in the baseline raster.

I think we can more/less solve this problem by switching the LULC crosswalk table to simple_combined_structure.csv instead of unique_combinations.csv. We can do this when we next do #127. Doing this will slightly exacerbate the other problem:

2. It could include some combinations of categories that are illogical, because of inaccuracies in the underlying LULC.

But we likely won't notice that too much. And we should still plan to solve that problem by labelling some codes as off-limits.

[davemfish]

We should do this at the same time as #127 , and both are on hold until #133

[davemfish]

Done in #139