Implement life-cycle model for FLUTE sessions

[rjb1000]

When the rt-libflute library is used by the MBSTF (as specified in 3GPP TS 26.502 and TS 29.581), the MBS Distribution Session may switch between an inactive and active state based on explicit configuration (e.g. timers) or as a consequence of certain failure scenarios.

To support this, we would like to be able to temporarily suspend a FLUTE session without destroying its internal state such that it can be reactivated at a later point with the same TSI and knowledge of previous TOI usage in that session.

As well as being able to (de)(re)activate an existing FLUTE session, we would also like to be able to create a FLUTE session in an initially inactive state. In this state, objects can be added to the session by the library invoker, but no packets are actually transmitted until the FLUTE session is activated.

[davidjwbbc]

I've implemented activate() and deactivate() methods on the Transmitter class and added an optional active parameter to the constructor which defaults to active (to maintain previous behaviour). Noticing a few bits of odd behaviour of reactivated FLUTE sessions, like extra FDT packets, which I'm investigating. Some of the issues I've seen may be due to the interactions of the MBSTF during testing.