Add reason to GET /status response

[FragLegs]

As discussed in our most recent call, this PR adds an OPTIONAL "reason" to the response from a GET /status request.

The other work of removing subjects from the /status endpoint will come in a later PR because I suspect it may be more contentious.

[appsdesh]

Thinking out loud here. Should we support I8N style reason similar to CAEP and RISC events?

            "reason": {
                "en": "System is down"
            },

[FragLegs]

That's an interesting idea. I was imagining that this reason would usually come from the Receiver via the reason field in the POST /status endpoint, but might sometimes come from an internal process within the Transmitter. Would we need to push that i8n to the POST /status endpoint as well?

[appsdesh]

Since the reason is for the human consumption it would make sense to include it in the POST request from the receiver during stream update call as well.

If this API is widely adopted and we are concerned about the compatibility issue while updating the request input then we could use a different key like receiver_ingested_reason or something similar in the POST request

[FragLegs]

I spent some more time thinking about this over the weekend. I think that we should assume that "reason" acts like an enum. That is, whether a Receiver or Transmitter changes the status of the stream, it will be because of a programmatic response to events with a small set of possible reasons. We should assume that Transmitters will make known the possible reasons and Receivers will be aware of their own possible reasons. These strings are not really for human consumption, so I don't think we need to internationalize them.

Does that make sense to you? I can update the example reason to something like SYSTEM_DOWN to make it more obvious how we intend for these to be used.

[appsdesh]

That makes sense to me! Thanks for spending cycles. LGTM