XMLTools: add support for UTF-8 with BOM prefix

This avoids a spurious "Content is not allowed in prolog" error that
Java normally emits when attempting to parse an XML document with UTF-8
encoding that includes a BOM:

http://www.rgagnon.com/javadetails/java-handle-utf8-file-with-bom.html
PrairieReader: implement a real data structure

The usage of parallel arrays makes it very difficult to guarantee robust
behavior in the case of missing and malformed data. The code is also
harder than necessary to understand. The new Prairie metadata structure
provides a "1st class citizen" for accessing Prairie-specific
information. It will also ease later migration to the SCIFIO structure.
Rewrite PrairieReader to be more robust

This change utilizes the new PrairieMetadata data structure, improving
on the behavior of the previous reader implementation as follows:

1. PrairieView is capable of acquiring multiple stage positions (i.e.,
   multiple Images), but does not differentiate them in the metadata in
   any way. Rather, all time points at all positions are simply numbered
   sequentially as "cycles" and conflated.

   However, we can disentangle stage positions from time points by
   comparing stage positions. If we notice a repeating pattern of stage
   positions, we record them as multiple series in the core metadata.

   PrairieView acquires planes for all positions at a given time point
   before moving on to the next time point. Hence, the rasterization
   order is always P faster, T slower; e.g.:

     P1T1, P2T1, P3T1, P1T2, P2T2, P3T2

2. PrairieView numbers each Sequence (i.e., stage position / time point
   pair) with a "cycle" value, each Frame (i.e., focal plane of a
   Sequence) with an "index" value, and each File (i.e., channel of a
   Frame) with a "channel" value. These values are 1-based.

   In our experience, the XML is always recorded in sequential order.
   However, the new implementation does not assume that will always be
   the case. Rather, it attempts to gracefully handle missing Sequences,
   Frames and Files, using the cycle, index and channel metadata as the
   canonical definition of how each TIFF file fits into the dataset. One
   useful consequence of this flexibility is that the reader now
   supports partial Prairie datasets: if the run is interrupted before
   completion, PrairieView produces a partial dataset, with no XML
   elements or TIFF files beyond the point of interruption. This is
   useful if, for example, the desired phenomenon or occurrence is
   observed taking place before the acquisition is complete; there may
   be no reason to continue the run after that point.
PrairieReader: avoid NPE from missing attributes

If linesPerFrame or pixelsPerLine is missing, we fall back to using the
first TIFF file's Y or X size, respectively.
PrairieReader: fix bug in logging statement
PrairieReader: Add PrairieMetadata#getSequences

This method returns the list of Sequences ordered by key. It will be
useful to handle cases where the cycle numbering does not increment one
at a time (e.g., for metadata with cycle=2,5,8,11,... or even for
non-linear increment patterns).
PrairieReader: handle any sequence numbering

PrairieView is capable of producing data where the cycle numbering does
not increment one at a time (e.g., for metadata with
cycle=2,5,8,11,...). We have not yet observed any datasets with
variable, non-linear increment patterns (e.g., cycle=2,4,5,11,12,...),
but this new approach should handle that too.

The new approach works by explicitly creating and sorting a list of
existing sequences, then using that list as the basis for sizeT & sizeP,
rather than assuming that Sequence#getCycleCount() will be sensible.
PrairieReader: fix handling of inverted Z/T

In the case where a Sequence is flagged as a TSeries, the Frames of that
Sequence must be treated as time points rather than focal planes. This
logic was previously not fully propagated through the code.
Merge branch 'develop' into prairie-fixes

Conflicts:
	components/bio-formats/src/loci/formats/in/PrairieReader.java

The conflicts are due to the FormatReader#core variable changing from a
CoreMetadata[] to a List<CoreMetadata>. PrairieReader.java has been left
intact in accordance with the prairie-fixes branch; the core data
structure changes will be addressed in the following commit.
PrairieReader: fix core metadata population

It required an update to reflect the new data structure:
List<CoreMetadata> rather than CoreMetadata[].
PrairieReader: use Boolean.parseBoolean
PrairieReader: use Locations instead of Files
PrairieReader: reset singleTiffMode when closing
PrairieReader: fix bugs in sequence indexing

Thanks to Melissa Linkert for noticing.
PrairieReader: always populate AcquisitionDate

Thanks to Melissa Linkert for pointing this out.
PrairieReader: parse acquisition date

I somehow missed this before, so it was always null.
PrairieReader: add missing final keywords
PrairieReader: parse active channels from CFG file
PrairieReader: use active channels metadata

This is required to properly handle cases where some channels are active
and others are not, as defined in the CFG metadata. For example, we have
datasets with "*_Ch1_*.tif" and "*_Ch3_*.tif" planes acquired, but no
"*_Ch2_*.tif" files.
PrairieReader: remove obsolete channels logic

We no longer care about which channel min/maxes exist per frame, as we
rely totally on the CFG metadata to determine the desired channels.

To be absolutely sure that all of our sample Prairie datasets have
channel metadata given in CFG, I did a quick check:

    find . -name '*.cfg' -print0 | xargs -0 grep -L channel_

And indeed they do. If we come across a dataset in the future with this
information missing, it would be pretty easy to synthesize based on the
per-frame channel min/maxes again, but until then, we don't need it.