Update project licenses

This branch updates the licenses for all Bio-Formats / SCIFIO projects. The following things have been updated:

1. Basic license metadata ("&lt;licenses&gt;" section) in each project's POM, identifying the project license. This metadata is mainly used when generating a Maven project web site. We include it for consistency, clarity and completeness.

2. Plugin configuration in each project's POM for license-maven-plugin, necessary for the following items 3 and 4.

3. LICENSE.txt file in each project base directory with a copy of the license for that project. These files were generated using "mvn license:update-project-license" from the toplevel directory, as well as the components/native directory. They can be regenerated as needed in the same way.

4. Individual file headers for every source file of every project. Each header now has a blurb appropriate to the enclosing project's license, prefixed by a copyright statement indicating the year range and copyright holders. The headers were stamped using "mvn license:update-file-header" from the toplevel directory, as well as the components/native directory. They can be restamped as needed (e.g., to update the year range or copyright holders) in the same way.

In doing this work, a number of issues arose, which I summarize below. I consider them all to be points for discussion, which should be resolved prior to this PR being merged.

1. The ome-xml project had a different style of copyright than the others. It used the OME copyright template, which begins with e.g. "Copyright (C) 2009 - 2012 Open Microscopy Environment" and then enumerates the constituent institutions on following lines, one per line, indented. Aesthetically, I really like this, as it is readable and identifies us all as members of the OME consortium very clearly. So, I styled the new ome-xml file headers in the same way. However, the rest of the projects are not styled this way. I propose that we make a decision one way or the other, for consistency, and I will update this branch accordingly.

2. Similarly, the ome-xml project includes MIT and NIH as copyright holders, unlike any other Bio-Formats project. This does make sense as members of MIT and NIH were heavily involved in crafting the original OME schema, from which the entire ome-xml codebase is derived. So I left them in as copyright holders. Do you all agree that this makes the most sense?

3. In components/bio-formats, the source file BDReader.java includes an additional copyright holder: Vanderbilt Integrative Cancer Center. Should we include this additional copyright holder for that one file? Note that BDReader.java also has an author tag that gives proper attribution. The difference here is that we have had many contributors to Bio-Formats (see <a href="http://loci.wisc.edu/bio-formats/authors">Bio-Formats Authors</a> page or components/bio-formats/pom.xml for a list) but none of the other contributors have explicitly retained copyright in the copyright holders section of the relevant source file(s).

4. Related to #3 above, it is possible to configure license-maven-plugin so that it does not overwrite the copyright holders portion of the file headers. In this way, we can maintain the copyright holders of each source file separately, as per OME general policy. Currently, this branch configures the license-maven-plugin to allow overwriting/updating of the copyright holders to match what is given in the project POM. Should we change this?

5. The components/scifio project contains a few XSL files that had a different copyright than the rest of the project. They were labeled as LGPL, copyright Glencoe Software. This branch updates them to match the rest of SCIFIO, which changes the license to BSD-2. Note that as part of the SCIFIO refactoring (on Mark's scifio-refactor branch), these files will move out of components/scifio and into components/ome-xml, which is also licensed BSD-2 now. Please comment if there are any problems with this relicensing.

6. Similarly, the components/metakit project was copyright Glencoe only, and the components/stubs/lwf-stubs project was copyright LOCI only. I have updated all projects to include at least UW-Madison, Glencoe and U. Dundee as copyright holders, since we have all invested much effort in developing this suite of projects. Are we agreed that this blanket application of those three copyright holders is OK? Or should we retain a smaller subset of copyright holders for relevant projects?

7. The project forks in components/forks did not have proper licenses. That is, we had left the original copyright holders with the original license, without adding our own copyright headers. We need to have our copyright and license "over top" the original ones, so I have done this, keeping the original 

8. BF-ITK-pipe had some files with an Apache2 license, copyrighted by Insight Software Consortium, blanketed over top of our copyright header with BSD-2 license. This was due to substantial contributions from Gaëtan Lehmann (the approach and initial implementation of bf-itk-pipe was his idea). I preserved the Insight Software Consortium as a copyright holder on bf-itk-pipe, but reverted the license to BSD-2 to match the others. (Though I personally don't have much preference between Apache2 vs. BSD-2. The ITK codebase is largely migrating to Apache2 from BSD, which is probably why they stamped Apache2 over those files.) There is currently a <a href="http://review.source.kitware.com/#/c/2112/">patch set to include BF-ITK-pipe in ITK proper</a>, and a corresponding <a href="https://issues.itk.org/jira/browse/ITK-2692">JIRA issue for it</a>, but it is currently marked as "Abandoned" as the Gaëtan has been too busy to pursue it to completion. If BF-ITK-pipe is included in ITK in the future, they can relicense Apache2 again, but until then, this branch sets the license to BSD-2. Sound OK?

9. Finally, this branch touches the vast majority of files in the repository. I have tried to group the commits so they are easy to review (for each source file, the old headers are removed and new headers added in same commit, for quick visual comparison). The testing burden of this PR is hopefully low: we need only verify that the code all still builds with Maven, since it touches all the POMs. That said, by and large, the sorts of problems this PR might introduce will not be caught by the compiler, or by runtime tests. We need manual code review of the header changes, to make sure nothing else fell through the cracks.

Sorry for writing a novel here but there are a lot of little things to think about! Thanks for reading!