Add description of stability guarantees for feedback messages

[alvestrand]

The feedback message path is still an immature aspect of the specification; we are pretty sure it is needed for optimal performance in some scenarios, but we do not yet have a firm grasp of which signals need to be sent. We should give some guarantees so that existing applications can be "future-proof" when feedback messages change.

Suggested guarantees:

• Applications will work if all feedback signals are discarded
• For "transform" style applications, system performance may be better if the application passes all feedback signals unchanged from the "downstream" MTG to the "upstream" MTS, and will never be worse than when discarding signals

[guidou]

These suggestions make a lot of sense, but we have removed the feedback channel, so closing this issue for now.