Mirroring CVS commit from mhiley on Inquiry 1318.

Added another alias for "BrightnessTemp" so that more data sources will
have inverted color table as default.  Tested with GOES-EAST/WEST and
MSG from SSEC, local MODIS, and GE-IR on adde.ucar.edu [1318]
Mirroring CVS commit from mhiley on Inquiry 1303.

* Temporarily adding a copy of AreaImageFlatField.java so we can test binary override before submitting to Unidata. (Remove this after pull request!)
* Override 5-arg binary in AreaImageFlatField
* Override binary in _MappedAreaImageFlatField
* Modify _MappedAreaImageFlatField constructor to construct from either imageUrl or existing AreaImageFlatField
* Modify testADDEImage for new _MappedAreaImageFlatField constructor

[1303]
Renaming a few convenience functions.

Removed prefix from "_today", "_tomorrow", "_yesterday", and
"_expandpath" as well as marking the old names as deprecated.

Names (new and old) have been added to the McIDAS-V global namespace.
Mirroring CVS commit from kevinb on Inquiry 135.

[135] I am unable to get the Low Pass 2D Contrast Image filter to
perfectly match up with -X. There are currently only 10 pixels out of
1085600 that do not match up and they are only off by 1 degree. There
are many more pixels that match only because of some jumping through
hoops to make them match due to some issues between how McIDAS-X rounds
(with the nint function) and Jython rounds (with the round function)
Here are some issues:
1. Raw data as retrieved from getFloats in Jython comes in as, say,
123.4999999, but shows up in -X as a raw value of 123.5.  As part of
the Low Pass 2D Image filter, this raw value will be rounded up to 124
in -X, but down to 123 in V. Thus, the calculations will not match up.
Hence, I created a function lowPass2DRound to convert the value into a
string and look for instances of .4999999, then rounding appropriately.
2. Unfortunately, McIDAS-X occasionally does have raw values come in as
123.4999999, so the rounding fix in Issue #1 then does  not work. This
is the case with the 10 non-matching pixels above.
3. In Jython, there are a couple of cases where the round does not work
as expected. A value is, say, 12.5, but round(12.5) becomes 12 instead
of 13 as expected. I printed this value out to many decimal places and
it said 12.50000000, so not sure what is going on here. To fix this, I
added 0.0000001 to the value passed in the first lowPass2DRound call.

Low Pass 2D is the only image filter that uses rounding within its
core, so this is why the matching process has been more difficult.
I am open to suggestions or someone looking at my work for the Low Pass
2D filter. But I believe this is as close as I'm going to get in
comparing the image filters between the platforms and that a perfect
match cannot be achieved for this test case.
Mirroring CVS commits from tommyjasmin on Inquiry 978.

This is just minor cleanup from working on JFileChooser
FileFilter.accept() problem
(gets called way too often).  Pulled Suomi JFileChooser extension class
out into its
own source file.  Made Swing app and tested to prove this issue is
INDEPENDENT OF MCV.

Tweak logging and note that accept() getting called after any mouse
movement
seems to be a Java bug and nothing to do with McV [978]
Mirroring CVS commits from tommyjasmin on Inquiry 978.

Fix bug William found where 12Z data was getting parsed and labeled 0Z
data [978]
Merge remote-tracking branch 'upstream/master'