Add default region scope that matches any scoped packet that doesn't match any explicitly defined scopes

[ElectroMW]

In response to issue #1751 here is a proposed change that would provide a resolution to a catch-22 problem that is hampering region scope adoption.

Rationale

Currently if a client starts scoping packets, any repeater that doesn't explicitly have a region scope rule for that scope will simply drop the packet. There have been attempts to implement scoping (London and WAW to my knowledge but probably others), but these have failed as currently it would require a local area to get almost 100% of repeater owners to change settings simultaneously.

So clients simply don't bother setting scopes as it doesn't work for them. Repeater owners don't bother because very few clients are scoping their packets.

So, by having a default scope, that defaults to allow 'F'lood, the default behaviour for both scoped and un-scoped packets is to be repeated, whilst not reducing the ability of repeater owners to restrict traffic. This is particularly helpful for dealing with repeater owners who largely setup then ignore their nodes.

This means, once enough repeaters have upgraded to the relevant FW version or newer, additional attempts to roll out scoping can be implemented gradually by smaller numbers of nodes (there are already working groups of "trunk" repeater owners able to co-ordinate their repeaters' scope setup simultaneously to encourage the rest of the mesh) without tanking traffic or without creating counter-productive client frustration.

Over time, when a critical mass of scoping rollout has been achieved, repeater owners can simply toggle 'any' to deny to replicate current functionality. If need be, in the future, 'any' could be changed to default to deny in a future FW release.

Changes

This change creates a second special RegionEntry, 'any,' that is largely handled in the same way as the existing 'wildcard' RegionEntry. It takes 1 byte from the current "reserved header" for persisting the 'any' flag.

For data export purposes, 'any' is appended to the end of the list. For get/set purposes, 'any' is resolved before user defined scopes, like the * scope and cannot be deleted.

Currently if a repeater has a user scope called any, it will be functionally overridden by 'any' and couldn't be deleted. My thoughts are that that is rarely enough to be the case that it wouldn't warrant extra handling.

[ripplebiz]

This ID would have to be something like 0xFFFF, well out of the typical/normal range. 'next_id' will just keep incrementing, over time, and only ever goes up, so 'normal' ID's could easily reach 33 and beyond.