Add navigation capabilities to CcPanel

These are structural changes that make our CcPanel panel base class capable of managing subpages in a way that is simpler for each panel implementation.

This work is the foundation for our future plans of extensively using AdwNavigationPage pages for nested setting UIs. See #3020

The new CcPanel methods are now documented in https://gitlab.gnome.org/GNOME/gnome-control-center/-/wikis/shell/CcPanel

Conceptually, we are now making every CcPanel class have its own AdwNavigationView by default. With this, panels that want to present a subpage should simply need to use something similar to:

cc_panel_push_subpage (CC_PANEL (self), ADW_NAVIGATION_PAGE (page));

With these changes, we also take ownership of the "subpage" UI handling. In commit d62f0480 we added the CcPanel.subpage which each panel could connect to in order to load its subpages. Now, setting the CcPanel.subpage at startup will automatically create a subpage and push it to the top of the panel navigation. This allows for deleting a lot of duplicated code in various panels with navigation.

Since we are now handling subpage loading equally for all panels, we also introduce a reusable mechanism to store subpage tags and page-types, allowing to create subpages on demand. This way, calling CcPanel.add_static_subpage (CC_PANEL (self), "thunderbolt", CC_TYPE_BOLT_PAGE) will add a low-performance-cost entry to a CcPanel internal storage table, and that can be used to create a CcBoltPage (for example) when needed/on-demand. All in all, this allows for panels like the "System" panel to not load all its subpages at startup, while also allowing the Privacy panel to add subpages conditionally. This should be used by panels when linking to a resource-hungry subpage without having to load it at panel startup.

The bulk of these changes that affect .ui files are basically removing AdwNavigationView objects, so those are better off reviewed without identation changes. Using git show -w, for example.