Bump to pom-scijava 1.35

This is needed to fix .lut discovery inside .jar files.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Fix misleading README.txt in ij-data.jar's luts/ directory

The main idea of having LUTs inside a .jar file is to allow them to be
overridden by the user without having the original file being marked
as locally modified by the updater.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Move all LUTs into ij-data.jar

We provide a set of default lookup tables. We want users to be
able to override them by putting their own version into the luts/
directory. If they would have to override ImageJ's own files, the
updater would always mark them as locally modified. That is why we
added the option to put default lookup tables into .jar files so
that the originals do not have to be overwritten by the user. But
that means that we should also use that option.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
LutFinder: do not expect a valid app directory to be present

If there is one, we should look into its luts/ directory. If there
is none, however, we should still look into the .jar files' luts/
directory without complaining too much.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We must not ask a String to do a File's job

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Fix finding .lut files in .jar files

We really need to look in all .jar files.

Besides, there is no use in listing all files in a directory and its
subdirectories, then throwing away the information which base directory
we were looking into, and then trying to reconstruct said base directory
from the URLs.

Instead, we need to discover LUTs as String/URL combinations, the String
being the menu path and the URL being the location where to find the
actual lookup table. Hard-coding the expectation that the base
directory's suffix is '/luts/' and the additional assumption that no
submenu in Image>Lookup Tables can ever be named 'luts' is not something
we are going to do.

This breaks the public API of the LutFinder in a rather blatant way, but
since we are still in beta phase and since it is not a cross-project API
for the moment (no collaborator uses the LutFinder directly), we can
still fix that without having to deprecate things.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>