LU-7437 utils: continue on errors in lctl {get,set}_param

The lctl get_param, list_param, and set_param code was accidentally
changed from "handle all parameters and return any error at the end"
to "stop at the first failed parameter and return an error".

The "try all parameters" behaviour was originally implemented by
user request in 2.2.90-14-g5ad45a6 http://review.whamcloud.com/3245
but appears to have recently been broken in v2_7_63_0-45-g2d11035
by http://review.whamcloud.com/17223 moving lprocfs_param_pattern()
into the parameter handling loop rather than in the *param_display()
functions.  The new error handling for lprocfs_param_pattern() was
handled as an error, when it would previously only have been saved.
This was further aggrivated by the reorganization to cfs_get_paths()
in v2_7_66_0-10-g85cbe1a.

Restore the old error handling and add tests to verify it works.
Print error messages whenever parameter processing fails before
continuing to the next parameter, so that the user can see which
parameter(s) had the error.  Include the operation type in the
messages printed by param_display(), since this is available.

The cfs_get_paths() patch also broke "lctl list_param -D" handling
(print only directories) by returning an error when this option was
used because display_param() returned NULL for non-directories (so
they wouldn't be printed), but the error handling treated this as
ENOMEM.  Move the handling for non-directories out of display_param
to avoid this, and add a test for "lctl list_param -D".

Fix a new memory leak in display_name() if realloc() fails.  Use the
existing param_name and don't append the type suffix in this case.

Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Change-Id: I710585a4b8614f00e3837560a968cd4f0c300c1e
Reviewed-on: http://review.whamcloud.com/18338
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Nathaniel Clark <nathaniel.l.clark@intel.com>
Reviewed-by: Bob Glossman <bob.glossman@intel.com>
Reviewed-by: James Simmons <uja.ornl@yahoo.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>