Add optional key to config values as mutually-exclusive with default

[kofalt]

It is sometimes handy to use the presence of a scalar to trigger some conditional behavior. For example: a radius, which when set will add the flag --radius to the algorithm's command-line invocation.

This conflicts with the manifest's need to provide firm assurances to the gear as to the structure of data it will be provided. For example: many languages cannot distinguish between a set, falsey / zero value, an unset value, or a null value. This ambiguity would make it difficult or impossible to correctly process a manifest.

So: let's make it opt-in. The optional key marks that a value may or may not be present at all in the config.json. This is mutually-exclusive with default, since it would be ambiguous to resolve the two.

Caveat: Depending the interface a consumer uses, an optional string value may not be very helpful. For example: in the web interface, empty strings should be sent if not filled out. @lmperry and I discussed this and it seems fair that since the algorithm opted into this, it's reasonable to have it deal with that.

This value is always provided, and defaults to zero:

"speed": {
	"type": "integer",
	"default": "0",
	"minimum": 0,
	"maximum": 3,
	"description": "How fast do you want the gear to run? Choose 0-3."
}

This value is only provided if set, including zero:

"speed": {
	"type": "integer",
	"optional": true,
	"minimum": 0,
	"maximum": 3,
	"description": "How fast do you want the gear to run? Choose 0-3."
}

This value is (probably) always provided by a web interface, and provided if set by a CLI interface:

"name": {
	"type": "string",
	"optional": true,
	"description": "What is your name?"
}

[kofalt]

This got 👍 from @lmperry, @ehlertjd, and @gsfr, marking as settled.