Develop a full unit testing framework for OpenLLDP

This is a minimal proof-of-concept for a unit testing framework that can be used with OpenLLDP. The first focus is to try to fully test out the various code paths that is in the `get_mac()` function which was recently updated in PR #122. This is currently a viability test to see how easy that can be done while requiring as few changes to the existing code as possible to support it. It is currently able to test a few paths in that function and only required a small change to `lldp_util.c` to implement.

https://github.com/penguin359/openlldp/tree/test-netlink

To run the test, run `./test-netlink.sh` inside the top-level folder of the checkout.

As I don't want to rely on the code actually talking to the kernel's `AF_NETLINK` subsystem, I decided to try using `socketpair(2)` to create a back-to-back pair of `AF_UNIX` sockets for `get_mac()` to talk to instead. This allows the test framework to directly send and receive all the datagrams destined for the `RTNETLINK` subsystem. This led to the one change that I had to make. As `get_mac()` creates a new netlink socket for each request, I had to break out that part of the rest of the logic which I moved to `get_mac2()`. The only logic left in `get_mac()` is the call to `socket(2)` and then it passed the result to `get_mac2()`. The test framework directly calls `get_mac2()` passing it half of the UNIX socket pair that was created.

Another function that needs to be stubbed out is `ioctl()` which is used by `get_mac()` to turn the ifname into an interface index number. To avoid having to modify that code, I used the linker flag `--wrap` which changes call to `ioctl()` to call `__wrap_ioctl()` instead which I can use for the stub. As the test doesn't currently care about the index, I just let it get left at zero for the time being.

With that taken care of, I was able to generate some RTNETLINK responses and verify that `get_mac2()` properly parsed out the MAC address from them.

I've avoided pulling in any specific test framework for this proof-of-concept so far, but I think [Unity](https://www.throwtheswitch.org/unity) or [GoogleTest](https://google.github.io/googletest/) could be interesting frameworks which I've used before. The current test is just using the standard library `assert()` function. I'm planning on running this test to see the codes response to large (>1024 bytes) packets both before and after the merging of PR #112 as part of the complete proof-of-concept.

Let me know what you think.