Redirect standard error of 'which' to the null device

The 'which' command that comes with GNU/Debian, the operating system
we are using for development, does not print anything in case the
specified command is nonexistent or not executable — just exiting with
return code 1. However, the version bundled with Red Hat Enterprise
Linux, we have found out, prints PATH to standard error when the
command cannot be located. We need to capture this stream too, as,
either if 'which' succeeds or fails, we want it to run silently.
Disable photometric filters for which there is no light curve

Each StarDetailsGUI displays a button for each of the photometric
filters for which there is information in the LEMONdB, but it may
happen that the light curve of a star could not be computed in one or
more of these filters. Therefore, clicking on these buttons raises an
error as we are attempting to plot a light curve which does not exist.

In order to fix this, StarDetailsGUI.__init__ must set to insensitive
(i.e., gray out) the buttons corresponding to those filters for which
the light curve of the star does not exist. This also implies that,
when we double-click on a star in the overview of a LEMONdB, it must
open at the first filter, when sorted by wavelength, among those for
which the light curve of the star is known.
Expand comment on shared gtk.CheckMenuItem in StarDetailsGUI.__init__
Replace -1's for unknown star periods with empty cells

The visibility of the columns in a gtk.TreeViewColumn is determined by
the 'visible' keyword argument of its constructor, which specifies the
tree model column from which the attribute of the same name will be
retrieved. The cell is thus displayed only when the attribute is True.

This is exactly what we can use to get rid of those -1 values that, we
always knew it was temporary, we have been using when the period of a
star is unknown — simply leaving the cell empty is not an option, as
the values in a gtk.ListStore must always be convertible to the type
of the column. But if instead of -1 we use 0, the 'visible' attribute
will evaluate to False and thus the cell will not be shown.

Therefore, we now use the same column by which the gtk.TreeViewColumn
is sorted to also establish its visibility. This has required a minor,
additional change: as we are using the same index for both properties,
columns with the periods in days (a real number) must be sorted by the
column with the period in seconds (an integer). Otherwise, we would
get the "unable to set property `visible' of type `gboolean' from
value of type `gdouble'" error message — in other words: PyGTK seems
not to be capable of determining the truth value of a real number.
Use empty cells for unknown standard deviations too

The previous commit, 0516d80c, replaced -1's in the columns with the
periods of the stars with empty cells, but we are still using these
values for the corresponding standard deviations: if the light curve
could not be generated there are no differential magnitudes whose
standard deviation can be calculated either. Instead of a mediocre
-1, we also want to display here an empty cell.

To establish the visibility of these cells, which store floats, we
require an additional column for each standard deviation, as PyGTK
apparently cannot determine the 'visible' attribute from the truth
value of real numbers. These second columns, one per photometric
filter, store a boolean value indicating whether the corresponding
standard deviation must be shown — and are, of course, for internal
use, and thus hidden from the user.
Hide unknown standard deviations in detailed view of stars

Instead of the -1 values that we have, as a temporary measure, used
when the light curve of the star could not be generated and therefore
the corresponding standard deviation is unknown, hide those rows in
the gtk.TreeView with the details of each star. They still exist, now
using the module-level variable UNKNOWN_VALUE, but are not visible.