desisurvey doesn't work with new tile file about desisurvey

[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.