WIP: Add forward tables to handle unsafe network packets distinctly from vpn network packets

[nbrownus]

This PR adds two additional firewall tables to deal distinctly with packets that have a source or destination address within an unsafe network on either the inbound or outbound.

Packets that have a source address assigned to the sender and a destination address assigned to the receiver will continue to use the inbound/outbound tables.

Packets sent to the tun device (outbound):

• Source address matches an address assigned to the local nebula and destination address matches an address assigned to the remote nebula: outbound table
• Source address matches an address assigned to the local nebula and destination address matches an unsafe network assigned to the remote nebula: forward_outbound table
• Source address matches an unsafe network assigned to the local nebula and destination address matches an address assigned to the remote nebula: forward_outbound table
• Source address matches an unsafe network assigned to the local nebula and destination address matches an unsafe network assigned to the remote nebula: forward_outbound table

Packets received by the udp listener (inbound):

• Source address matches an address assigned to the remote nebula and destination address matches an address assigned to the local nebula: inbound table
• Source address matches an address assigned to the remote nebula and destination address matches an unsafe network assigned to the local nebula: forward_inbound table
• Source address matches an unsafe network assigned to the remote nebula and destination address matches an address assigned to the local nebula: forward_inbound table
• Source address matches an unsafe network assigned to the remote nebula and destination address matches an unsafe network assigned to the local nebula: forward_inbound table

Questions:

• Do we also need firewall.forward_inbound_action and firewall.forward_outbound_action, should they default to their existing counterparts if so?
• Should we split metrics based on forward or collapse them into the existing inbound/outbound metrics?
• Maybe unsafe_inbound and unsafe_outbound would be better names?
• Should we take this opportunity to deprecate the cidr rule and alias it to remote_cidr? Or maybe even better, remote_network and local_network?