Better filtering of MAVLink components

[stephendade]

This adds the appropriate filters so that MAV_COMP_ID_PERIPHERAL devices can be used without confusing MAVProxy.

EDIT:
This PR now allows any MAVLink accessories (same sysid as flight controller, different component id) to:
a) Not confuse MAVProxy if the accessory is sending a heartbeat
b) Selecting the accessory in the console->vehicle->select menu correctly filters packets from the accessory to non-multi-vehicle-aware modules.

[stephendade]

PR has now been re-engineered for the general case:

• self.is_primary_vehicle(m) now checks for component id matching, instead of using a hardcoded component id blacklist.

[stephendade]

It has been tested on SITL with the ADSB simulator, and a CubeOrange with custom MAVLink peripheral. Messages are still routed correctly.

[peterbarker]

This is a good change - components won't necessarily have the same timestamp as the parent vehicle.

[peterbarker]

Will this break mavproxy_gimbal.py? That's the first module I thought of...

[stephendade]

Checked - gimbal still works. I'm only not sending heartbeats here

[stephendade]

Using sim_vehicle.py --vehicle=Copter --console --map --count=10 --auto-sysid works fine

The changes in master_callback() still allow packets from the non-target vehicle to be passed through to multi-vehicle-aware modules (line 886 of mavproxy_link), as the check is for multi-vehicle aware modules.

[peterbarker]

fence module still says "fence removed" / "fence present" when moving between vehicles

Testing went well.

[peterbarker]

Merged, thanks!