Default filter does not work in APRSSharp CLI

[CBielstein]

Description

The APRS# CLI client has always supported a default filter so that packets can be received even if a user doesn't know how to craft a filter.

Unfortunately, it seems that #98 broke that default filter. Based on initial debugging, this appears to be because the result of Console.ReadLine() is never null, but simply an empty string. Since the default filter is only applied if the user-supplied filter string is null, the default never kicks in.

We need to resolve this issue in a way that allows AprsIsConnection to accept the option to not filter messages (e.g. programming a server) without exposing that to AprsSharp CLI.

This should likely be fixed with the following steps:

1. Update AprsIsConnection.Receive to have a default value for the filter parameter. Use that default value as the default filter.
2. Update AprsIsConnection.Receive to only apply the filter string if the filter parameter is not null. Thus allowing receiving without a filter.
3. Update the AprsSharp CLI client to only pass the user-supplied filter argument if it's not empty.

Acceptance Criteria

• [x] AprsSharp can again receive packets when no filter is supplied by the user
• [x] AprsIsConnection can connect without a filter (don't have to test this...it's considered bad practice to received unfiltered from a normal T2 server)
• [x] AprsSharp cannot specify a "no filter" scenario

[CBielstein]

Picking up this issue quickly to not leave the CLI broken. I'm going with the approach of moving defaults to the CLI app. AprsIsConnection clients will be more advanced in general, so the defaults aren't needed there. Indeed, it now appears that most servers are rejecting "N0CALL" as a login anyway.