local_domain_name not in compliance with Special-Use Domain 'home.arpa.' RFC 8375

### Prerequisites

- [X] I have checked the [Wiki](https://github.com/AdguardTeam/AdGuardHome/wiki) and [Discussions](https://github.com/AdguardTeam/AdGuardHome/discussions) and found no answer

- [X] I have searched other issues and found no duplicates

- [X] I want to request a feature or enhancement and not ask a question

### Description

#### What problem are you trying to solve?
**Setting local search domains and allowing DHCP to populate the domain to clients.**

Currently, the setting defaults to 'lan'. (This setting is not in compliance with RFC 8375.) Casual users are not notified of this except by reading the wiki configuration documentation. My Linksys router allows me to specify a local search domain, which is then populated to the clients via the DHCP process (as verified by my MacBook Pro in the network settings). After switching from the router's DHCP to Adguard Home's DHCP the search domain was not populated even with the default 'lan'.

#### Proposed solution

1) Be compliant with RFC8375 and change the default local_domain_name from 'lan' to 'home.arpa'. Even if you keep 'lan' the following suggestions are still valid.
2) Allow users to change 'local_domain_name' via the web admin interface.
3) Notify them of the default setting in the web interface and allow changes.
4) Have your DHCP server the local_domain_name to clients.

#### Alternatives considered
Manual updates to AdGuard Home and Clients where they available in their settings

#### Additional information
https://www.rfc-editor.org/rfc/rfc8375

The domain name 'home.arpa.' is to be used for naming within
residential homenets. Names ending with '.home.arpa.' reference a
zone that is served locally, the contents of which are unique only to
a particular homenet and are not globally unique. Such names refer
to nodes and/or services that are located within a homenet (e.g., a
printer or a toaster).

DNS queries for names ending with '.home.arpa.' are resolved using
local resolvers on the homenet. Such queries MUST NOT be recursively
forwarded to servers outside the logical boundaries of the homenet.

Some service discovery user interfaces that are expected to be used
on homenets conceal information such as domain names from end users.
However, in some cases, it is still expected that users will need to
see, remember, and even type names ending with '.home.arpa.'. The
Homenet Working Group hopes that this name will in some way indicate
to as many readers as possible that such domain names are referring
to devices in the home, but we recognize that it is an imperfect
solution.

But compare with RFC6762

Some network operators setting up private internal networks
("intranets") have used unregistered top-level domains, and some may
have used the ".local" top-level domain. Using ".local" as a private
top-level domain conflicts with Multicast DNS and may cause problems
for users. Clients can be configured to send both Multicast and
Unicast DNS queries in parallel for these names, and this does allow
names to be looked up both ways, but this results in additional
network traffic and additional delays in name resolution, as well as
potentially creating user confusion when it is not clear whether any
given result was received via link-local multicast from a peer on the
same link, or from the configured unicast name server. Because of
this, we recommend against using ".local" as a private Unicast DNS
top-level domain. We do not recommend use of unregistered top-level
domains at all, but should network operators decide to do this, the
following top-level domains have been used on private internal
networks without the problems caused by trying to reuse ".local." for
this purpose:

.intranet.
.internal.
.private.
.corp.
.home.
.lan.