The firewall does not support IEEE 802.1Q VLAN tagging

The firewall inspects the ethertype and rejects anything that doesn't match IPv4, IPv6, or ARP.

In the IEEE 802.1Q VLAN tagging case, an IEEE 802.1Q header is placed between the source MAC and the ethertype containing a tag protocol identifier and tagging information. The firewall thus reads the tag protocol identifier (typically 0x8100), sees that it doesn't match IPv4, IPv6, or ARP, and rejects the packet.

**Potential fix:**

To fix this, I suggest that we:
- Define a `struct TaggedEthernetHeader` that matches the Ethernet header in the IEEE 802.1Q VLAN tagging case;
- Before we [parse the ethertype field](https://github.com/CHERIoT-Platform/network-stack/blob/af597abd03da8b4832d2b4678d5cac9833d3af61/lib/firewall/firewall.cc#L1023), check if its value corresponds to IEEE 802.1Q VLAN tagging;
- If so, re-cast into a `TaggedEthernetHeader` before entering the Ethertype switch.

We should do that on ingress and egress.

A similar solution could be applied to support other forms of tagging such as IEEE 802.1ad double tagging, though I doubt we need support for that now.

**Notes:**

This should not be considered a priority, as the FreeRTOS+TCP stack [does not currently support VLAN tagging](https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/blob/main/source/include/FreeRTOS_IP.h#L56). Adding support for VLAN tagging to the firewall without support in the network stack is not useful.

We will have the same problem with the incoming DNS resolver: https://github.com/CHERIoT-Platform/network-stack/pull/50

Start in lib/firewall/firewall.cc around the ethertype parsing at line 1023, then locate the corresponding egress path. Review the IEEE 802.1Q header layout and the FreeRTOS+TCP VLAN-support limitation before changing the firewall. Done means tagged ingress and egress packets are handled without being rejected as unknown ethertypes.

Written by the indexing model from the issue text.