Include the 'sasl', 'runtime_tools', and 'recon' applications when
building a release with the 'default' profile.

Mention all directories that needs to be installed.  And suggest a list
of files to be patched rather than modifying the `build.config` file, as
the latter currently has some limitations.

Don't exclude applications when building a release with the 'distro'
profile, as those applications would also be omitted from the boot file.

If eturnal is running in 'interactive' mode (e.g., in a `rebar3 shell`),
application:ensure_all_started/1 will usually succeed in starting up all
(transitive) dependencies, while eturnal_module:start_app/1 will fail if
dependencies aren't installed below code:lib_dir/0.

When searching for a dependency in the library directory, don't assume
application directories will always include a version number.

Avoid calling application:get_env() directly.

Running `eturnalctl help` doesn't require superuser privileges.

Remove 'conf' from the list of release applications.  It's listed as a
dependency in eturnal's app file, so Relx includes it automatically.

Allow modules to call eturnal_module:ensure_deps/2 in order to load
dependencies which eturnal doesn't hard-depend on.

Log a proper error message instead of crashing if a module callback
fails, and add some debug output.

While at it, update the 'stun' dependency for improved debug output, and
to get 'stun_query' events for STUN-only listeners as well.

The default blacklist is only applied if no 'blacklist' entry is
specified in the configuration.  So, don't make it sound like individual
blacklist entries might be appended to a configured list of entries.

Add experimental support for modules and include a `mod_example` with
the source code.  The APIs aren't documented yet and may change in the
future.

Include the 'runtime_tools' application when building a release with the
'prod' profile.  The 'runtime_tools' application is required to trace
processes or to run things like Erlang Top or Observer.

The child specification's 'id' of TURN workers is 'undefined'.

Distributions usually install stripped binaries.

Let extension scripts check whether the eturnal node is currently
running, rather than failing with an unclear error message.

The new `eturnalctl session` command lists details about the currently
active TURN sessions.

The log output generated by the 'stun' application has been improved in
the following ways:

- Append session ID, transport, username, and client IP addresses/ports
  to STUN/TURN log messages.
- Append relay/peer IP addresses/ports to TURN log messages.
- Log amount of relayed traffic per TURN session.
- Log plain STUN (Binding) responses.
- Log more info level messages during TURN sessions.
- Log error responses sent to STUN/TURN clients.

Call `echo "$e" | sed "$s"`, not `"echo "$(echo "$e" | sed -e "$s")"` to
parse errors returned by eturnal.

Set the viewport for the generated reference documentation page in order
to make it more mobile-friendly.

When applying listener changes on configuration reload, sleep half a
second after stopping the old and before starting the new listeners (as
a workaround to avoid timing issues leading to EADDRINUSE errors).

Set the 'ip' address in the 'listen' example to "::", and remove
incorrect comments (there's no default 'ip' value).

Catch eturnal_logger:set_level/1 failures rather than letting
eturnal:handle_call/3 guard against invalid log levels.

With systemd versions older than 235, an /opt/eturnal/run directory will
be created by default.  If such a directory exists, delete it on package
removal.

If the "Vendor" field isn't specified, FPM will set a meaningless
default value.

Binding epmd to a specific IP address lets it implicitly bind to ::1 as
well, which can go wrong on IPv4-only systems.  See, for example, the
following thread:

https://erlang.org/pipermail/erlang-questions/2016-March/thread.html#88408