Issues/37 unittests

[tresf]

Adds basic read/write unit tests by starting up a virtual com port using socat.

If socat is missing, the test will automatically be skipped.

Partially addresses #37

[tresf]

Merging so that we can have this on master for other useful tests. I believe in the future we may want to split out the threading logic from VirtualPortRule to clearly indicate that it's part of the unit test, not the rule which invokes the test, although I appreciate -- for simplicity's sake in the tests -- why the current design approach was taken. I'm also curious if this type of bootstrapping inside a rule is common for JUnit.

On a personal note...

Secondly, I'd like to offer my apologies for initially pushing back on this PR.

• When I had originally spoken with @scream3r (the original author of JSSC) back when the fork was originally created, he made a great emphasis on the fact that "JSSC" stands for "Java Simple Serial Connector", and as such, "too much tooling" defeats the purpose of keeping it simple.
• One (in my opinion, strong) point that @scream3r made was that often serial port issues need physical hardware to be tested due to the intricacies of a bad, interrupted or unexpected data.
• Furthermore, depesite -- personally -- coding Java for most of my career, I'm embarrassingly not very familiar with JUnit (I still, to this date find it extremely difficult to read and understand).
• Lastly, and mostly unrelated to this PR, but perhaps the project's tenure in general -- maven --I still find to be a bloated mess for such a small project, where most of the time is spent waiting for it to fetch a myriad of dependencies, which become more and more evident as build systems move to immutable OSs (such as in a container). I wholeheartedly dislike the maven build system with every ounce of my being (this has not and likely will not changed) and find myself staring blindly at nearly unreadable XML, when I'd much prefer something like CMAKE, QMAKE, bash, etc (I'd even be happier with ant, tbh).

That said, the maven build system we use is pretty reliable and the junit tests -- although nearly impossible to read the output from -- are the best we have right now, so I'm sorry if this causes pushback where it's not warranted, or perhaps misdirected.

I do still believe that @scream3r's "simple" principal can still apply here whilst still allowing modern features, but I can do that without driving away good contributors, and for that, I'm sorry.

[tresf]

Sorry, this came in a merge commit, it was intended to be a squash commit.