Implement diopsid as a dripline service

[casesyh]

use the simple shell base class to write a service that provides access to disk usage, available from the df bash command

[laroque]

@danielgarratt (and @guiguem, @wcpettus)

I took some time to look over feature/easy_scheduler at the end of the day today. I'm a bit uncomfortable with the solution and at first wasn't sure why. Having mulled it over, I think that probably what happened is that you've made a reasonable direct port of the logic as it exists in diopsid, while I was reviewing it from the perspective of canonical dragonfly implementations. In particular I think some questions I'd ask are:

1. Why does this class not inherit from Spime and implement an on_get method, rather than dealing with a lower level scheduled_action and send_alert methods?
2. Why does this class take a list of storage locations and almost the entire body of the primary implementation method exist in a loop over those locations, rather than having the class instance be configured to look at a single storage location and use multiple instances to allow monitoring of multiple locations?

This is a bit of a refactor, but it shouldn't actually be too bad and has the advantages that:

• this would be structured in a way which is parallel to the rest of the system
• we'd have the option using the un-uniform time spacing feature (or any other similar feature added later)
• we'd be able to get the current value of individual drives (and include it in snapshots, use it for run logic, etc.)

[wcpettus]

staging for release in v1.13.0