Updates to faciliate the mocks run on pixel-level imaging data.

[geordie666]

This PR updates general utilities and the code that generates randoms for "real" data to help the mocks interface with the pixel-level Legacy Surveys coadd images. It includes:

• A new function geomask.get_brick_info() that looks up the brick names associated with HEALPixels at a given nside.
• Updates to randoms.quantities_at_positions_in_a_brick() to add a justlist option to list the required input files for that function. Note that passing justlist returns the maximal possible set of files needed to run quantities_at_positions_in_a_brick(), which can, in fact, run with few (or zero!) imaging files for any particular brick.
• A few irrelevant and minor bug fixes and documentation updates.

[geordie666]

@michaelJwilson: I think this is the remaining functionality you need for #608. One subtlety is that, depending on how you're setting up your Legacy Surveys directory environment variable, you may want to pass that directory through pre_or_post_dr8() first to get a north/south split, before using justlist. For example:

from desitarget.randoms import quantities_at_positions_in_a_brick, pre_or_post_dr8
lsdir = '.'
quantities_at_positions_in_a_brick([1.], [1.], '0006m002', drdir=lsdir, justlist=True)

will return a "non" north/south split set of files, but:

for dd in pre_or_post_dr8(lsdir): 
    print(quantities_at_positions_in_a_brick([1.], [1.], '0006m002', drdir=dd, justlist=True)) 

will return a north/south split set of files.

[michaelJwilson]

Looks perfect, thanks.

which can, in fact, run with few (or zero!) imaging files for any particular brick
For posterity of the discussion, while it would run the result could be argued to be entirely spurious and it's debatable whether this is a useful feature. Especially as it negates many checks against a user doing what they intended. There's arguments either way. Thanks!

[geordie666]

I'll give this a few hours and then merge so @michaelJwilson can continue working on his branch.

[geordie666]

And, for the record, I disagree with the "results could be argued to be entirely spurious". As written, if quantities_at_positions_in_a_brick() does not find, say, an nexp file for g-band in a particular brick, then it correctly populates the passed random locations in that brick with NOBS_G=0.

I suppose, ideally, the Legacy Surveys could always supply an nexp file for g-band and populate it with zeros where there are no g-band observations. I think it's probably simpler to just assume that no g-band file means no g-band observations in that particular brick, though.

As Mike noted, there's arguments either way!

[sbailey]

FWIW, looks good to me.