Tomas/connection raii initial

[ProfessorTom]

Before submitting a pull request:

• Did you fork from the development branch? yes
• Are you submitting the pull request to the development branch? (not master) yes

This will likely be a Cthulhu PR that will need to be broken up into a few smaller PRs once the work is done. Unfortunately, the way through is a long running branch in the short term.

Some benefits and thoughts as work continues on this branch:

TcpThread class will be replaced with BaseTcpThread, OutgoingTcpThread and IncomingTcpThread.

The idea here is to combine common code in the base class but separate the different directions so that they have room to breath and you can follow the main flows more easily. All three of those classes will automagically clean up both the socket and the threads via RAII and Qt's object lifecycle and parenting system.

There will be a root Connection class, a BaseTcpConnection class, an IncomingTCPConnection and an OutgoingTcpConnection class.

Here's the basic idea:

Connection (abstract)
│
├── BaseTcpConnection
│ ├── OutgoingTcpConnection
│ └── IncomingTcpConnection
│
├── BaseDtlsConnection
│ ├── OutgoingDtlsConnection
│ └── IncomingDtlsConnection
│
├── BaseUdpConnection
│ └── UdpConnection (usually no separate in/out)
│
└── ... (future protocols: RS-232 [aka Serial] QUIC, WebSocket, SCTP, etc.)

Unit tests have been added for code I have modified or added and will continue to be added for code I modify or add.

qMake is likely going away.

I'm not sure how Dan builds for each platform.

I was under the impression that most if not all platforms were using CMake now. I know snapcraft and macOS does. Regardless, the unit test only work with CMake, in part, because I am developing on a Mac. There may be some way to get the unit tests to build and run with qMake, but as I understand it, Dan wanted to move away from qMake anyway, so now's the chance.

This means I should be able to delete the .pro files in this PR. At the time of this writing I am not doing so because I don't know what the consequences are for taking that action. e.g. there may be one build that is still using qMake. I talked with @dannagle and he said that Windows stills needs to be converted to CMake. I know that the snapcraft build uses CMake. Not sure about the Debian build in the pipeline.

This likely means modifying the build process to build and run the unit tests and perhaps have such failures block PR merges. While the latter can be done once here on GitHub, the former will have to be done on each platform that PacketSender is built for. Given we are dealing with some low-level functionality (e.g. IPv4 vs IPv6, os default network stacks, etc.), it's possible that some unit tests may fail on platforms other than macOS. I haven't tested on any other platform. I fully intend for this to be a problem for Dan to solve, not because I'm being lazy or want to give Dan more work, but because at the time of this writing, this PR is not complete and I don't have access to each build system to test them.

Fixes #151