OSRImportFromProj4() incorrectly parses some valid PROJ.4 parameter strings

[paul-grass@…]

===1===
If the string includes a + sign not as the initial character of a parameter,
e.g. as part of the exponent of a number, it is incorrectly parsed.
e.g.
+proj=lcc +x_0=0.6096012192024384e+06 +y_0=0 +lon_0=90dw +lat_0=42dn 
+lat_1=44d4'n +lat_2=42d44'n +a=6378206.400000 +rf=294.978698 
+nadgrids=conus,ntv1_can.dat

===2===
A Transverse Mercator parameter string that uses the 'preferred' +k_0=n rather
than +k=n (see http://remotesensing.org/lists/proj_archive/msg00067.html) to
indicate the scale on the central meridian has the scale factor set to the
default of 1 instead of n in the resulting WKT.
e.g.
+proj=tmerc +lat_0=53.5000000000 +lon_0=-8.0000000000 +k_0=1.0000350000 
+x_0=200000.0000000000 +y_0=250000.0000000000 +a=6377340.189000 +rf=299.324965 
+towgs84=482.530,-130.596,564.557,-1.042,-0.214,-0.631,8.15

(both the example strings were created by the GRASS g.setproj program and work 
fine for use with PROJ.4, but I was trying to add some functions to GRASS to 
export the co-ordinate system in WKT format and came across these problems).

Paul Kelly

[warmerdam]

Committed a fix in ogr_srs_proj4.cpp so allow use of k_0 any place k would
be allowed.  This should resolve the second issue. 

[warmerdam]

I have committed a fix to ogr_srs_proj4.cpp to handle this.  The module now
has a local custom PROJ.4 parsing function that takes this situation into account.

Also added tests for both problems in gdalautotest/osr/osr_proj4.py. 

I am still looking into the pj_init_plus() function which I think has a similar
problem. 

[warmerdam]

Similar problem with handling of plus signs existed in proj.4's pj_init_plus().
This has been corrected too.