PolyUtils.polyval refactored to work with java arrays
Interim commit for Coregistration work
Experimental package for 'LS estimation' problems in Java

- contains methods for 'proper' estimation of the coregistration
  polynomial building on top of different LA libraries in JAVA

- methods for data snooping / outlier removals

- also contains lots of experimental and R&D code

- benchmarks of different JAVA LA libraries - reflected in pom

- also different collection libs evaluated (guava, trove, etc.)

- ...to be cleaned up after integration -> ppo.commons
Refactored coregistration branch to jLinda

 - refactored by merging master branch into coreg branch
 - couple of minor conflicts resolved in merging (core/pom.xml)

Conflicts:
	jdoris-core/src/main/java/org/jdoris/core/utils/PolyUtils.java
	jlinda-core/pom.xml
Interim commit: Refactoring of Core Coregistration classes to jLinda
Major clean-up of Coregistration method unit tests
Refactoring of internal and testing methods: modifiers set to private, and changed names
Resampling development : interim commit
Resampling - completed development and testing
Start work for reorganization of Coregistration functionality:

 - moving non-open-source code into open-source branches
Merge branch 'master' into coregistration
Removed not necessary matrix initialization in PolyUtils.polyFit2D()
Clean up of logging in PolyUtils, logger level set to 'warn'
Cross InSAR functionality - jLinda core classes

 - core class computes the (dummy) coregistration polynomial based on ratios
   between original and target sampling frequencies

 - prototype implementation is in unit test

ToDo: see code for details.

Note: Since everything is deterministic PolyUtils.polyFit2D is used in the estimation
of polynomial. No need for data-snooping and outlier removal. This is quite straightforward
and efficient.
Mission / Sensor field in SLCImage()
Add ToDo note for issue#10: "Inconsistencies between polyfit and polyval methods of PolyUtils class"
New convenience method for distributing points in MathUtils

 - construct grid of points as int[][], and for convenience cast it and then return it as double[][] array
Fixed bug, reorganized a bit, and refactored variables in CrossGeometry

 Bug fix: stupidly polynomial used to be constructed on target and not on the source geometry;
 in polyfit2d A design matrix would be wrongly computed, leading to errors that would scale
 up with with the size of solution space and ratios. Actually the bug was in 5 years old
 matlab protype....

 Rorganization: estimation grids now as class fields. I have to call them if I want to use
 JAI.WarpPolynomial

 Refactoring: more sensible variable names.
Prototype and experimental implementation for polynomial estimation and evaluation using different methods

 - shoot-out between different polynomial estimation and evaluation methods
       1st method - jLinda.polyFit2D
       2nd method - jLinda.polyFit2D with normalized variables
       3rd method - JAI.WarpPolynomial
       4th method - polynomial estimation using jLinda, evaluation using JAI

       => as expected jlinda.polyfit with normalized the most stable
       => JAI has problems on its own

 - it is based on matlab and javaschool closed-source code

 - this implementation exposes problems and inconsistencies with polyUtils

 - note that JAI seems to introduces bias in evaluation of polynomial

ToDo - to be removed after operator committed
Quick bug-fix : flipped variable names when refactoring