Avoid pushing default dog identifier to TOPO server.

[bitonality]

The following behavior was observed when using an Alpha 100 as the host GPS.

Issue:

1. Add collar to host GPS by using the track code.
2. Host GPS initiates packet communication using "Dog" as a placeholder name while waiting for the user to edit the text name of the collar on the host GPS device.
3. Tracker console gracefully handles the collar name changing, but this leaves a hanging reference on the TOPO server to a "{Callsign}-Dog" that is no longer receiving updates from the tracker software once the user updates the collar name on the host GPS.

This change proposes that we internally track collars as usual, but we skip pushing to the TOPO endpoint if the identifier is default ("Dog").

[bitonality]

Alternatively, we could swallow the entire packet, but that would require logic changes with the internal identifier map (negligible performance impact). Advantages of swallowing the packet would be parity between the logged tracker file and the TOPO server internal db (1:1 log entry:TOPO server update).

I might also try sniffing packets during the add-collar-by-code routine to see if there's some sort of state that can be captured that would indicate that the collar is added to the device, but is unnamed (seems iffy though).

@mcosand Let me know if this issue is important enough to warrant a PR.

[mcosand]

I believe for the majority of users, their device setup is static while using this program. It may be unlikely, but I'd hate to filter out messages that the user was intending on seeing. For now, I'd rather see this in your private build, or behind a command line argument.