Make `custom_tables` for nftables smarter

[pitkley]

DFW has to be able to act on traffic when it traverses any one of the input or forward hooks. This can be achieved in one of three ways:

1. Have no other tables that hook input or forward, leaving only DFW's table.

   This is not really feasible, because that would leave you with an entirely open firewall, at least until DFW has run.

2. Ensure that any existing tables that hook input or forward don't drop the traffic before it reaches DFW's tables.

   This is not great if you want your input hook to have a drop policy, which I personally would always want, just to make sure I don't accidentally expose any port I didn't intend to expose.

3. Let DFW know about any existing tables and chains that hook input or forward.

   This is what the custom_tables setting does and it give us the best of both worlds: we can ensure that DFW can correctly accept traffic it is responsible for while still being able to default drop traffic in the input hook.

It is fair to assume that most default nftables installations will have the inet table with chains that hook input and forward, so it would be nice if the user didn't have to specify the custom_tables configuration.

One way to not require the user to do this would be to run nft --json list ruleset within DFW, parse the JSON output and identify the chain that acts on the traffic first (i.e. the one with the highest priority value). DFW can then hook into these chains as it does when custom_tables is defined.

(Relates to #705.)