Add the ability to return different DNS records based
on the client's subnet.

For example, for host `foo.example.com` clients from
`10.0.0.0/8` may get `1.1.1.1` where clients from
`192.168.0.0/16` may get `2.2.2.2`, etc.

The new implementation is kept as separate as possible
from existing Unbound code. Eg the model section, controllers
and new UI tabs, are all separated. This means that

1. Existing code/state is minimally affected
2. Users who are not interested in (more advanced) view
functionality see no UI changes to existing, familiar menus,
and do not have to spend time thinking about new view options.
3. Corner cases are removed - the separate model
section avoids solving for these cases in logic
4. Support is easier: because view logic does not overlap
with existing logic (e.g. separate unbound configuration file
generation logic, separate API controllers, separate xml state)
fault isolation should be easier.

Note that unbound's view local-data (host) records are slightly different
than standard local-data (host) entries:

```
view:
  local-data: "ccc.example.com. A 3.3.3.3"
```

compared with

```
server:
  local-data: "ttt.example.com  IN A 7.7.7.7"
```

The new `Split View DNS` menu under unbound has three UI tabs:

 "Views", "Subnets", "Hosts".

These match the following flow:
Users create a View, create a Subnet to scope the view to, then
assign Hosts to that View.

A Host can be assigned to multiple Views. A Subnet can
be assigned to a single View; multiple Subnets can be
assigned to the same View. This behaviour is reflected
in the model (and validation).

Subnets cannot overlap - this behaviour is recommended
and means that View order does not matter.

If a View is deleted, Hosts are no longer assigned to that
view. If the Host was assigned to multiple Views it remains
assigned to the remaining existing views. Otherwise it
it is unassigned, and can be associated with a different
View if desired. (It does not become part of the "server:"
section - that would be a potentially dangerous side effect.)

The Hosts table has a Views dropdown which can be used to
filter Hosts based on View. This dropdown and all tables
update automatically if changes are made (eg if a View name
is changed that will be reflected automatically in the Hosts table,
the Hosts filter, and the Subnets table).

There is no support for interface based views, but the
design would easily support adding that. (Interfaces would be
assigned to views in the same way as subnets.)

Reverse records are created automatically. Only A/AAAA
record types are supported. Wildcards are supported
using `*`.

Updates are saved atomically. E.g. If a view is deleted,
it is removed from the Host state and the view state
atomically, so there should be no stale references.

For some design discussion, and UI screenshots see:

 opnsense#8952