Add FOP-1 routing and management

[sneakyaardvark]

This PR adds the sending end of COP-1, FOP-1, as a channel routing option. It is disabled by default.

The CopManager service handles the Higher and Lower Procedures for all FOP-1 instances. This also includes CLCWs, which are handled by the router to the manager, which then handles sending them to the correct FOP instance.

General Operation

In a "normal" situation, where FOP-1 is the end operating on the ground, it is trivial for an operator to press a button to terminate and reactivate the FOP state machine, should retransmission time out or other alerts occur (this is how it works in YAMCS). However, on a satellite in orbit, this is not as convenient! The Higher Procedures for FOP-1 have automatic recovery actions when alerts or other problems occur, instead of forwarding them to the user. Ideally recovery takes only a few service loops, and at worst 1.5 minutes (after this timeout, FOP is reinitialized from scratch). Additionally, if FOP stops receiving CLCWs (default 3s timeout, same as YAMCS), it automatically suspends service until it has ground station contact again.

Usage and Drawbacks

Overall, the API is meant to be as simple as possible to users (the EDL). The EDL only has to add to a queue as before, and the FOP procedures handle everything else behind the scenes. The main drawback is that if a problem with the retransmission system itself occurs, there is no way to alert the user and the frames are dropped (with logged warnings). Recovery is still automatic and unless something is really wrong future frames will downlink just fine after recovery.

Does it work?

I have written a batch of unit tests, which is about as good as it gets for now, since we don't have a ground station FARM implementation yet. The FOP-1 service itself works fine, as shown in #90.

[sneakyaardvark]

Not sure about the test failure. Only happens with unittest in this repo, not for pytest in ccsds-cop. And it doesn't seem to be an issue at runtime.