Add message window with the parameters of the first search algorithm

This is the first algorithm for data analysis that, after our last
meeting with Matilde Fernández, we are going to implement. This commit
does not add any real functionality other than the dialog window which
allows to configure the parameters of the search. It has also been
added a new submenu, 'Find', where the first data analysis algorithms
that we have in mind will be placed.

What this search algorithm will do is allow the astronomer to identify
those stars whose light curve amplitudes increase (on decrease, as the
user prefers) with the wavelength. For example, if the photometric
filters of the light curves were Johnson B, V and I, the stars found
by this method would be those whose A{B} <= A{V} <= A{I} (or the other
way around, if the user chooses so), where A{x} represents the
amplitude of the light curve in the photometric filter 'x'.

The amplitude of a light curve is defined as the difference between
its maximum and minimum, but we are taking into account that there may
be outliers, product of measurement errors, that could significantly
distort the result. In order to prevent this, amplitudes are defined
as the difference between the mean or median of the maximum and
minimum values in the light curves.

An option for excluding from the search stars with 'noisy' amplitudes
has also been included. To determine whether the amplitude of a star
is noisy, we calculate how many times it is greater than the mean or
median of the standard deviations of the light curves of other stars
with the most similar brightness. If this ratio is smaller than the
threshold selected by the user, the amplitude is marked as noisy and
the star is discarded.

Note that, in the dialog window, the radio buttons adjacent to the
"Amplitudes must be sorted by" text have the labels "BVI" and "IVB".
These are temporary values: in subsequent commits they should be
updated dynamically to reflect the actual photometric filters for
which there is information in the LEMONdB.
Encapsulate the message window in its own class

This may not be necessary for simple message boxes, but the window
with the parameters of the search algorithm will not only allow the
user to adjust them: more complex functionality (such as disabling
those that are not applicable or transparently interacting with the
configuration file) is expected. The way to go, therefore, is to
move the window into its own class, AmplitudesSearchMessageWindow.
Disable widgets when the option to exclude noisy stars is unchecked

If the checkbox to exclude from the search stars with noisy amplitudes
is unchecked, disable the widgets (radio and spin buttons) that adjust
the parameters used to determine whether an amplitude is noisy — since
they are not going to be needed there is no point in allowing the user
to set them.
Add LightCurve.amplitude method

This method returns the peak-to-peak amplitude of a light curve – that
is, the difference between its peak (highest value) and trough (lowest
value). In order to avoid arbitrary results because of outliers caused
by measurement errors, the mean or median of multiple points can be
used as the peak and trough.
Add LEMONdBMiner.amplitudes_by_wavelength method

The first version of the search algorithm does not exclude stars that
have noisy amplitudes, focusing only on whether the amplitudes in all
the filters are directly or inversely correlated with the wavelength.
In other words, we are only interested in whether the star has light
curves in all the photometric filters and their amplitudes increase
or decrease as the wavelength of the photometric filters moves up.

As we intend to make use of a progress bar in the GUI to allow the
user to get a rough estimate of how much time the operation will take,
the algorithm has been implemented as a generator which always returns
something, so that it is possible to know exactly how many items the
generator has stepped through.

A two-element tuple is returned for each star that satisfies the two
conditions, with (a) the ID of the star and (b) a list of two-element
tuples which map each filter to the amplitude of that light curve.
None, on the other hand, is returned if the conditions are not met.
Add LEMONdB.most_similar_magnitude method

In order to determine whether an amplitude is noisy, we will need to
compare it to the standard deviation of the curves of other stars with
similar instrumental magnitudes. Since checking whether a star has a
light curve is not insignificant in terms of performance (an access to
the database is needed in each case and the query is not simple), how
these stars are identified can be implemented as a generator: first
they are sorted by how similar their instrumental magnitude is, and
only then, one by one, we check whether they have a light curve.
Allow LEMONdBMiner.amplitudes_by_wavelength to ignore noisy stars

The method can now, optionally, exclude from the search those stars
with one or more 'noisy' amplitudes. The amplitude A of a star S is
considered noisy if the ratio between A and the median (or mean)
standard deviation of the curves of the N stars in the database with
the brightnesses (instrumental magnitudes) most similar to that of S
is below a threshold.

The last element of the tuple yielded when a star is found becomes a
list of three-element tuples (instead of two-element ones), as they
now must also include the median (or mean) standard deviation of the
comparison standard deviations. In case noisy stars are not ignored,
these standards deviations are set to None.
Add AmplitudesSearchMessageWindow.get method

There are many widgets in the interface, defined in Glade, to which we
need access through the gtk.Builder class. This method saves us from
having to type self.builder.get_object over and over, which results in
(slightly) less code redundancy.
Run the search for stars by their amplitude from the message window

Although we are still not doing anything with the found stars, the
value of the different parameters in the dialog window is read and
passed to LEMONdBMiner.amplitudes_by_wavelength. It is necessary to
modify the search.amplitudes_search function to make it receive as
its third parameter the path to the LEMONdB.
List actual photometric filters in the labels of the radio buttons

As mentioned in commit fe87f656, the dialog window has "BVI" and "IVB"
as the text of the radio buttons used to select whether the returned
stars must have their amplitudes directly or indirectly, respectively,
correlated with the wavelength. These labels convey perfectly what the
radio buttons do, but it is not hard, and looks much better, to set
them to the real photometric filters in the LEMONdB when the dialog
window (AmplitudesSearchMessageWindow) is created.
Use a progress bar to display the progress of the search

The search for amplitudes correlated with the wavelength, especially
when noisy stars are excluded (the "Filter out those stars with one or
more..." check button) is an expensive task and may take more than the
user would expect. Thus, a gtk.ProgressBar, which grows as stars are
analyzed by LEMONdBMiner.amplitudes_by_wavelength, is used to indicate
the percentage of the work that has been completed.

The search can be canceled at any time by clicking 'Cancel', while
clicking it when no search is in progress closes the window. In order
to avoid running two or more searches in parallel, the 'Ok' button is
disabled as soon as the stars start to be analyzed.
Memoize some methods of LEMONdBMiner

The LEMONdBMiner.amplitudes_by_wavelength method, particularly when
stars with noisy amplitudes are excluded from the search, is rather
slow: not only its current implementation takes quadratic time, but
it also requires way too many database accesses.

Mitigate this by memoizing three of the methods of the LEMONdBMiner
class: get_star, get_light_curve and get_period. In this manner, we
make these methods avoid having to access the LEMONdB a second time
for the same star, achieving a considerable speed-up. However, this
also means that databases accessed through the LEMONdBMiner class
should be read-only, as otherwise the methods would return outdated
data if the star were modified after the first call.
Display search results on a new page of the gtk.Notebook

The AmplitudesSearchPage class receives, one by one, the stars found
by LEMONdBMiner.amplitudes_by_wavelength, populates with them a
gtk.ListStore and creates the gtk.GtkTreeView needed to display its
contents. The get_window method returns a gtk.ScrolledWindow, whose
child widget is the tree view of the stars, that we append as a new
page to the gtk.Notebook of the LEMONJuicerGUI class.
Fix LEMONJuicerGUI.handle_close — did not work with the search results
Disable the 'Amplitudes' toolbar button when no LEMONdB is open

Both the toolbar button and the menu item (in the 'Find' menu) must be
insensitive when the GUI starts up, as it is already the case with the
'Close' button, and remain so until we open a LEMONdB. If the LEMONdB
is closed, they must be disabled again.
Open star details from the search results too

As it also happens with the list of reference stars shown when a
LEMONdB is opened, allow the user to double-click on any of the stars
found by LEMONdBMiner.amplitudes_by_wavelength to see its details.
Fix error (% operator used incorrectly)