don't broadcast basic ID via BLE legacy if it is not set

[BluemarkInnovations]

If the user did not configure the Basic ID in the parameters, don't transmit those Basic ID packets via BLE legacy transmission method (if enabled). For other transmission methods, the odid_message_build_pack() will take care of it.

This PR Is a small enhancement to PR https://github.com/ArduPilot/ArduRemoteID/pull/73 So, if the user would not set the Basic ID 1/2 in the parameters, but the module receives Basic ID information from MAVLink/DroneCAN, only broadcast this received ID. And don't also broadcast a basic ID message with empty data.

This allows maximum flexibility for all scenarios in which Remote ID modules are used.

[BluemarkInnovations]

I think this PR is still valid given the merged dual ID implementation. Don't send basicID messages if it is not set.

[tridge]

@BluemarkInnovations I've fixed the merge conflicts, but Basic-ID is mandatory in ASTM, do you really think we should skip it? I would have thought a blank Basic-ID would be more robust, as you could tell the difference between packet loss and bad config

[BluemarkInnovations]

@tridge In retrospect, this PR is not that important. This is a situation in which the ArduRemoteID module has not set any basic ID and or ID/UA type to zero. That means that the OPEN_DRONE_ID_ARM_STATUS message will also report an error to the user.

So it is a question how to handle such situation. My opinion is not the broadcast invalid data.

Bad config vs packet loss. In case of bad config even with this PR you will receive other BT4 legacy packets, only the basic ID info will be empty. In case of packet loss you won't receive other BT4 legacy packets as well.

[BluemarkInnovations]

I think this one is obsolete and superseded by https://github.com/ArduPilot/ArduRemoteID/pull/103