String version of Metric does not include min or max values, even
if they were present in the string passed to the constructor.

String version of Metric does not include values for warn, crit,
min, max if they were specified as 0. This happens because their
inclusion in the string representation of Metric was conditional
on their boolean value (which is false for 0). Changed to check
for None instead.

String version of Metric did not collapse None values into empty
semi-colon delimited sections, causing input of ;;1 to result
in ;1 on conversion to string.

When to uom is % min and max were always forced to 0. This causes graphs to always have 0 and 100 for min and max, even if other values were supplied.
This is changed to only force the default values if no other values had been set.

In addition, when converting a Metric to a string, those same min and max values were always included. If they are actually 0 and 100 that is not necessary, and they are now left out, but only if not explicitly specified on input.

These changes allow control over the appearance of min and max lines in graphs, regardless of their desired values. If the value is specified, even when equal to a default, they will be output and thus graphed. If defaults were generated, they will not be graphed.

This leaves the semantics of the perfdata unchanged.

Previous change for handling defaults for min/max in perfdata without % was incorrect. We should distinguish between several use cases. The first is that when reading min/max for this case, the values should reflect defaults even if no values where specified. The second is that when these values were not specified, they should also not be reflected in the string representation. This was accomplished through two shadow variables.

The handling of quotes in metric names was incorrect. As written "outer quotes" which would be necessitated if the metric name contains at least one space, are not stripped resulting in the "name" property incorrectly still containing these quotes. They should be stripped and re-attached in the string representation only. Secondly all single quotes are stripped. This is wrong, as the specification states that single quotes in the name are to be represented by two successive single quotes in perfdata. Stripping would remove all trace of the quotes. The fix is to replace double-single-quotes with single quotes, after first stripping just the outer quotes, if presen. A related problem is that none of the input transformations on the name are "undone" in the string representation. This makes a re-parse of the string representation result in a non-identical result. The fix was to re-attach the reverse transformations.

Several test cases were added to catch the above scenarios.