fix: bm cfg of non-neighbors with new link-local forwarding

[towynlin]

Prior to this PR, given a topology of 3 nodes A | B | C, running on node A any bm cfg command that targeted node C would fail. The reason was that config commands are sent to the link-local multicast address, and node B, upon finding that it was not the target of the message, simply dropped the packet.

This PR adds the ability in BCMP to forward messages in that scenario, using a feature described in section 5.4.4.2 of the Bristlemouth spec that had not previously been implemented.

One additional requirement relating to the link-local neighbors-only address, which can help cut down on unnecessary transmissions, is that granular messaging limited to a specific Port can be achieved by setting a destination address with the pattern:

ff02::000X:1

Wherein X represents the egress port on which to direct the packet (as opposed to all available ports by default). As with the equivalent global all-nodes address pattern, these four bits shall be cleared before transmission on the relevant port.

This addressing feature can help to support more efficient execution of higher-level Bristlemouth functions relating to neighbor discovery, capability negotiation, and resource discovery, as these exchanges carry information associated with specific neighbors and network segments, which may not be useful or relevant to nodes on other segments.

---

Other minor changes:

• Renaming src_port to egress_port and dst_port to ingress_port for clarity using the unambiguous official terminology from the standard
• Noting in TODO comments some places where the current implementation does not conform to the published standard
• Noting in TODO comments that BCMP assumes a 2-port PHY in this forwarding implementation and that future effort should generalize
• Some clang-format cleanup