Add initial support for collecting and formatting performance data

[atc0005]

Extend current type to allow collecting performance data and returning it to the Nagios console.

One or more new fields, one or more new methods.

Providing and emitting performance data should remain optional.

[atc0005]

From https://github.com/atc0005/check-vmware/discussions/315:

Some notes for my later review:

• https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/3/en/perfdata.html
• https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/3/en/pluginapi.html
• https://nagios-plugins.org/doc/guidelines.html#AEN200

[atc0005]

Extend current type to allow collecting performance data and returning it to the Nagios console.

Looking at the https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/3/en/pluginapi.html coverage for "PERFDATA", we have the option of providing the formatted performance data on the same line as the initial first line of output (ServiceOutput), at the end of the output (LongServiceOutput) or both.

Emitting the output at the very end may be the simplest approach, but one potential problem is that if the LongServiceOutput content is too long it could result in the PerfData content being lost.

Perhaps we could stub in basic length checks to help determine where the PerfData output is emitted.

It's worth noting that I've been occasionally reviewing the one-line ServiceOutput text via CLI execution as one of my iterative testing steps prior to deploying a new service check. If we mix in the PerfData on the initial line it will "add noise" to the brief output.

[atc0005]

I've made some light progress on this, but still have a lot of work left to do. I'm currently going over the https://nagios-plugins.org/doc/guidelines.html#AEN200 doc and trying to get a sense of how to handle validation for the specific values that makes up a PerfData entry.

[atc0005]

Stubbed out some proof of concept scratch work. Hope to implement soon.

[atc0005]

Thought: function chaining. The first method returns a type that has a method which takes the second piece of data and so on. The net result is that we build the value we want in pieces.

This was clearer in my mind before I was woke up, so I am sure I am leaving something out.

[atc0005]

TODO: Update documentation to reflect changes from GH-87.

[atc0005]

Looks like the label naming practice is to use underscores. See https://github.com/atc0005/check-vmware/issues/321#issuecomment-920803154 and previous for additional notes.

I'll extend the doc comments for the Label field to help make that clear.

[atc0005]

See atc0005/check-vmware#321 for recent discussion and troubleshooting of the performance data output format. As of commit bb945df57a5d980094b70c12075c6018e4659c45, initial support is in place and ready for further use/testing. #92 is intended to refresh the documentation (such as it is) to cover the new support for emitting performance data.

The hope is that after some further use the better way forward will be clearer.

For example, here is a mockup of what method chaining might look like:

    nagiosExitState.
        PerformanceData().
        Label().
        Value().
        UnitOfMeasurement().
        Warn().
        Crit().
        Add()

    nagiosExitState.
        PerformanceData().
        Label().
        Value().
        UnitOfMeasurement().
        Max().
        Min().
        Add()

Ultimately I'm going to need to give this some time/thought before making further changes.