desisurvey doesn't work with new tile file

[sbailey]

desisurvey doesn't work with the new desimodel desi-tiles.fits that changed the GRAY program to layer 0 instead of layer 4. Tests fail sporadically since one of the symptoms is Scheduler.tnom being initialized with np.empty but then not completely initialized since self.tiles['program'] has values 3 and 4 instead of 1,2,3 around line 90 of desisurvey/schedule.py. I haven't chased upstream to see what is going wrong with the program assignment.

We may need to temporarily revert to the old desi-tiles.fits, but this will need to be fixed eventually, preferably in a way that doesn't hardcode which layer is which program (desi-tiles.fits should own that mapping).

[dkirkby]

An easy short-term fix would be to have desimodel.io.load_tiles swap pass numbers to preserve the original numbering, so we can use the new tiling now without having to take time out to sort out these issues.

[sbailey]

I like the idea, though I'd prefer to see the pass number swapping happen inside a desisurvey wrapper of desimodel.io.load_tiles so that only desisurvey is impacted. That will also make it easier when updating the desisurvey rules files because it won't require a simultaneous update to desimodel.

It appears that the PASS is propagated into the output plan.fits, scheduler.fits, and progress.fits files, where it would be inconsistent with desimodel/data/footprint/desi-tiles.fits but I don't think that it is actually used by any downstream code.

PROGRAM also appears in scheduler.fits as an integer instead of a string. That mapping would also be impacted, but is also not used downstream.

[dkirkby]

The new tile file should work after #91, although this still needs to be tested. All static tile info used by desisurvey and surveysim is now managed by a new (cached singleton) desisurvey.tiles.Tiles object, which wraps the underlying tiles FITS file. Quoting from the docstring:

Each tile has an assigned program name and pass number. The program names
(DARK, GRAY, BRIGHT) are predefined in terms of conditions on the
ephemerides, but not all programs need to be present in a tiles file.
Pass numbers are arbitrary integers and do not need to be consecutive or dense.

[schlafly]

The move from passes to no-pass makes this less important, since the rules and config files no longer reference PASSes and so this won't error out any more. There may be some residual plotting code somewhere that still uses the original PASS relationships, but it should be pretty much gone now. Closing until such code is specifically identified.