This allows displaying info such as Range, Increment, and Units when "param help PARAM" is used.

Hi @tridge.  @eliao noticed an interesting bug.  Some other GCS was talking
to the vehile and using the PARAM_REQUEST_READ variant which uses -1 for
the param_index (so just searching by string).  Due to a bug (IMO) in ardupilot
the vehicle was sending back param_values that looked like:

2015-02-22 16:54:48.04: PARAM_VALUE {param_id : WPNAV_ACCEL_Z, param_value : 100.0, param_type : 9, param_count : 462, param_index : 65535}
2015-02-22 16:54:48.08: PARAM_VALUE {param_id : WPNAV_SPEED_DN, param_value : 250.0, param_type : 9, param_count : 462, param_index : 65535}
2015-02-22 16:54:48.08: PARAM_VALUE {param_id : WPNAV_SPEED_UP, param_value : 150.0, param_type : 9, param_count : 462, param_index : 65535}

Notice in the mavlink xml that the param_index is a int16_t in the
request, but a uint16_t in the response.

These 65535s were confusing mavproxy (it was mistakenly adding a 65535 entry
mav_param_set).

* In ardupilot GCS_MAVLINK::handle_param_request_read it is sending back the param_index that was included
in the PARAM_REQUEST_READ, which is not correct.  It it should send back the actual index of the param we found (this is why mavproxy is seeing 65535).  I'll send in a PR to master to fix this.
* mavproxy gets confused when it sees 65535 - I'll make it treat it the same as the request

this will allow the tracker module to use the param handling

makes for faster interaction for show then set