AprsSharp can display decoded APRS-IS packets

[CBielstein]

Description

Currently, AprsSharp command line app prints out raw TNC2-encoded APRS packets. This is not very intuitive for the reader as most humans are not familiar with TNC2 and APRS encodings.

For this issue:

• Use the functionality introduced by #79 to decode packets and raise a new packet received event
• Printing out relevant fields

Since different APRS packet types have different relevant fields, there may be some work here to decide which fields are relevant. It's also okay to take an easy approach and refine later e.g printing all fields or printing specific common fields (e.g. callsign, comment, timestamp?, etc.).

Acceptance Criteria

• [x] New event in AprsIsConnection for receiving a packet which passes a decoded APRS packet
• [x] Update the AprsIsConnection unit tests to mock TcpConnection to return a valid packet string and assert an event is raised with the proper decoded packet
• [x] Human-readable decoded packet information is printed out in AprsSharp command line application

[CBielstein]

This issue is NOT about decoding all possible APRS packets. That is covered by Milestone 7. The point of this issue is to hook up better UI for printing out packets which we CAN decode. Once that's done, the issues in Milestone 7 will increase the packets we can decode.

So this issue should focus on UI in the console app and printing out human-readable information, which we can expand upon later.

[CBielstein]

Basic UI print logic is wired up in the packet refactor as part of #93, but it is likely still worthwhile to clean up the UI output here to be much cleaner.

We'll also definitely want to add an event to pass successfully decoded packets up to the client and switch Program.cs to use that instead of forcing all clients to handle decode logic directly.

[CBielstein]

I split the code-cleanliness part of this (as mentioned in previous comments) off in to #103 as #102 will actually resolve the original acceptance criteria of this issue.