Fix critical when parsing null date string:

GLib-CRITICAL **: 12:05:52.144: g_time_val_from_iso8601: assertion 'iso_date != NULL' failed

This is possible since tracker can return NULL[1] "if the column is
not in the [0,#ncolumns] range"

[1] https://gnome.pages.gitlab.gnome.org/tracker/docs/developer/tracker-sparql-cursor.html?gi-language=c#tracker_sparql_cursor_get_string

The libadwaita pkg-config adds `-I/usr/include/libadwaita-1`
(or similar) to the compiler flags, which means that

  #include <adwaita.h>

is sufficient, and the currently used

  #include <libadwaita-1/adwaita.h>

is not necessary.

Not only is it not necessary, but it prevents nautilus from being
built with an uninstalled libadwaita build (either meson subproject
or otherwise). To fix that, remove the `libadwaita-1/` prefix.

The libadwaita test programs also only `#include <adwaita.h>`, and
according to Debian Code Search, that is the more popular version.

https://codesearch.debian.net/search?q=%23include+%3Cadwaita.h%3E&literal=1
https://codesearch.debian.net/search?q=%23include+%3Clibadwaita-1%2Fadwaita.h%3E&literal=1

When renaming a file in list-view or grid-view, the renamed file keeps
its position (i.e. it isn't re-positioned into the new proper position)
until a refresh). There is actually a more generalized problem where
file changes on all attributes fail to cause the sort positions to be
updated. For example, sorting by date modified and touching a file
doesn't cause a re-sort.

The file-changes signal from nautilus-directory, simply gives us the
changed files for a given directory, without telling us what was changed
so there's not an efficient way of detecting this.  We do have a
::end-file-changes signal, that is only emitted once every batch of
changes, so let's call nautilus_view_model_sort() then.  If no sort
changes are required, this will finish quite fast, so it seems like
the best alternative.

Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2568

Now that we are properly freeing all view items, it became obvious
that we were incorrectly freeing a call to get_item_from_file
which is just a hash table lookup.

See: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1101

The `--talk-name=org.gtk.vfs` statement should not be used in manifests
as there is no service with such name. The `--talk-name=org.gtk.vfs.*`
statement should be pretty enough for the GVfs access. See:
https://docs.flatpak.org/en/latest/sandbox-permissions.html#gvfs-access
Let's drop that statement.

There are two error messages that may be shown when the delete operation
fails. One message is generic and the another one mentions insuffient
permissions. However, the generic one is now shown in the case of the
`G_IO_ERROR_PERMISSION_DENIED` error. Let's exchange the messages to
use the second one in this case.

This reverts commit 16c0a9b1.

This commit builds on commit d45b820d
which causes a crash.

This reverts commit d45b820d.

This commit causes a crash.

Currently, the `g_bus_own_name_on_connection` function is called for the
`org.freedesktop.FileManager1` name before exporting the
`/org/freedesktop/FileManager1` skeleton. This seemingly works fine in most
cases, but occasionally the name is acquired too early and D-Bus clients
can get `No such interface` error. This is regression caused by the commit
2293e813. Let's try to own the nam until
after exporting the skeleton to avoid this error.

I see regularly the following debug print on Nautilus startup:
`GLib-CRITICAL **: 10:52:52.992: g_hash_table_foreach: assertion
'hash_table != NULL' failed`. This is because the
`emit_change_signals_for_all_files_in_all_directories` function is called
before the `directories` hash table is initialzed. Let's return early
to prevent usage of the uninitialized hash table.

In nautilus_file_class_init, we are calling
thumbnail_limit_changed_callback() and show_thumbnails_changed_callback()
in order to cache the initial values for the static variables
cached_thumbnail_limit and show_file_thumbs.  This has the unintended
side effect of also calling emit_change_signals_for_all_files_in_all_directories ()
which doesn't make sense at a point in time when there are no
NautilusFile's and NautilusDirectory may not even be ready.

Split out the updating of the setting from the emission of
all files changed.

We are already caching the preferences for thumbnailing.  Since the
clock format is queried for every single file when loading a list view,
we should also cache the clock format setting.

Rename the flag from use_24 to use_24_hour for more clarity.