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.
Fix for broken/missing dependency

 - cherry picking and rebasing of functionality from coreg branch into master resulted
   in missing and broken dependencies!?
Quick patching of SLCImage for missing methods

 - Because of partial integration of coreg branch into master, SLCImage needs some functionality that's
   isolated in coreg while now also needed in master branch
Cherry-pick and start tracking LUT class from coregistration branch in master

 - LUT class encapsulates all functionality for creating and manipulating
 (eg. shift as fnc of fDC) of convoultion kernels for the interpolation/resampling of
 SAR StripMap data

 - Development is done in coregistration branch, and it is cherry-picked
 into master branch for Cross InSAR
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
Merge branch 'cross' into coregistration

Conflicts:
	jlinda-core/pom.xml
	jlinda-core/src/main/java/org/jlinda/core/SLCImage.java
	jlinda-core/src/main/java/org/jlinda/core/coregistration/cross/CrossGeometry.java
	jlinda-core/src/main/java/org/jlinda/core/utils/PolyUtils.java
	jlinda-core/src/test/java/org/jlinda/core/coregistration/cross/CrossGeometryTest.java
Quick bug-fix : flipped variable names when refactoring
Merge branch 'coregistration' into cross