Deprecate LegacyND2Reader

[sbesson]

This reader depends on an outdated DLL which has not been built in years, is untested and fully superseded by the new NativeND2Reader

In addition to the Java reader, the following components are scheduled for removal in Bio-Formats 7:

• lib/LegacyND2Reader.dll
• components/formats-gpl/src/loci/formats/in/loci_formats_in_LegacyND2Reader.cpp
• components/formats-gpl/src/loci/formats/in/loci_formats_in_LegacyND2Reader.h

Possibly biggest question is whether we want to keep the delegation logic implemented in ND2Reader which allows to select between the LegacyND2Reader and NativeND2Reader. Listing a series of options briefly discussed with @melissalinkert are:

1. redirect

   bioformats/components/formats-gpl/src/loci/formats/in/ND2Reader.java

   Line 47 in 971fb34

   legacyReader = new LegacyND2Reader();

   to NativeND2Reader.
2. keep ND2Reader but have it simply extend NativeND2Reader
3. remove ND2Reader and update readers.txt to use NativeND2Reader
4. remove the delegate reader and rename NativeND2Reader as ND2Reader

Given this is a backwards-incompatible change, my personal preference would go towards options 3 or 4 but definitely open to feedback. In case we go for the latter options, we might want to add other deprecation flags to some of these classes

[melissalinkert]

Option 4, 3, 2, 1 would be my order of preference for handling ND2Reader.

[dgault]

We will also want to add warnings to the format pages for each of these similar to Woolz ome/bio-formats-documentation#308

[sbesson]

Adding to Monday's agenda, we should decide on our removal strategy - see #4030 (review). In particular if we decide to go with option 3 or and 4, I could add a commit to annotate the classes that will be renamed with @deprecated to notify developers.

[joshmoore]

Brief discussion of an additional option:

5. move all logic to ND2Reader and have NativeND2Reader subclass it

It's not a strong opinion, but as came out in the chat, I would tend to opt for the least breaking change (but perhaps only since if I started letting myself adjust namings, I probably wouldn't stop... 😉) So a slight preference for 1 (with a warning if anyone chooses legacyReader) but a slightly stronger partial-preference for 5>4 with a deprecation of the updated NativeND2Reader subclass.

[sbesson]

Summarizing the weekly discussion, the preferred option seems to be migrate the NativeND2Reader logic into ND2Reader. For backwards compatibility, NativeND2Reader might be retained and simplified as a simple extension for as mentioned in #4030 (comment).

In all cases, this means NativeND2Reader is deprecated and consumers should be encouraged to depend directly on ND2Reader. Pushed 74f337c to try and capture this message although open to better ways to express this.