Adds jobs for adding and removing Sprouts

[kyleoliveira]

@Ohmbrewer/web-team Got another one for review...

Hold until #59 is merged (may need a rebase afterward).

Resolves #39 . Should provide some buttons on the Rhizome Management page that allow the user to flash Sprouts onto the Rhizome.

Notes:

• You don't have to clear all Sprouts when adding new Sprouts. So, if you need something for testing, you can hypothetically already set up a Sprout in firmware and add extra Sprouts via Ohmbrewer as long as there are no collisions. However, if there is a collision and you clear all Sprouts, the Sprout you added via firmware will get wiped until reboot.
• Currently, Temperature Sensor identification is a little weird since we're using the OneWire Address/ID as the unique identifier. I'll be revising that in a later Issue once we resolve Ohmbrewer/rhizome#32 . Until then, if you're going to use Temperature Sensors that aren't associated with a Thermostat or RIMS, supply the Rhizome Equipment ID for the sensor's OneWire address. Otherwise, add/remove will not work for that sensor. This shouldn't be any more of a showstopper than that Rhizome Issue is.
• Using the Clear Sprouts button/job will wipe out all the Sprouts on the Rhizome. Once we have a method for verifying what's already on the Rhizome, we can be more selective. In the meantime, you can manually launch a RemoveSproutJob to remove a single Sprout, but there is no UI element for that (or for adding a single Sprout for that matter) by design. It didn't seem worthwhile at this juncture - in most cases you may as well re-flash all the Sprouts.

[azyth]

looks good to me.

[azyth]

my only question pertains to the first note, if you have somethign accessed via a hard coded thing in firmware and it gets deleted, it will hard fault....correct? so we probably need to make sure we dont do that.

[kyleoliveira]

It will only hard fault if you're calling something on a specific Sprout and that Sprout is no longer there. Once the Rhizome is in loop(), all Sprouts are the same.

That's a Rhizome issue, not a web app issue - you'd run into that if you issued the same command the app is issuing but via the Particle CLI or curl. That shouldn't happen usually since the loop is only supposed to have a call to sproutList.work() in it. If you're supplying pre-initialized Sprouts for debugging purposes and are calling something on them manually in loop(), I'd hope you'd guard the call with an if-statement that checks if the pointer isn't NULL and that it still points to what you're thinking it does (i.e. you'd want to loop through the list and find the Sprout with the right Type/ID combo instead of using an index or something) or simply don't modify the Sprout list.