KF7: PagePool API

PagePool provides singletons of pages per URLs. It has multiple properties and methods to load new pages, manage loaded ones, and inspect what's loaded. However, those properties and notification signals can be improved to be more atomic and ergonomic.

First of all, given that this component is implemented in C++, operates on pointers to QQuickItem objects and does NOT use any Page-specific properties, maybe it should be renamed to reflect that it's a generic Item cache.

For properties, my suggestions is to unify lastLoadedUrl and lastLoadedItem into some kind of Q_GADGET so that they are atomic and share a common notify signal.

It would be cool to use QQmlPropertyMap for urls->items mapping, but unfortunately it only supports strings as keys. Another idea was to use ECMAScript Map class but there is no way to make it immutable for QML/JS (except to construct a new one on every READ call).

The PagePool::resolvedUrl method is too magical and better be removed. It is responsibility of the caller to ensure that URL is valid and resolved.

For another pure-QML type supplementing PagePool API, PagePoolAction, I have something to say about almost every property:

• // This property holds the url or filename of the page that this action will load.
  property string page

  Clearly this can not hold a real url object. And as I said about PagePool itself, automagic URL resolution should be dropped completely in favor of client-side explicit resolutions.
• property Item pageStack — quite loosely typed. Why not use a PageRow instead of plain Item?
• property Kirigami.PagePool pagePool — this should probably be required. There is no way this component can work without an externally provided page pool. Maybe default page pool should be embedded into ApplicationWindow/ApplicationItem?
• property QQC2.Page basePage — using styled QQC2.* components as types is a bad practice. It rarely adds anything useful to the type, but restricts any custom T.Page implementations. Unless it was meant to be specifically Kirigami.Page… !1146 (merged)
• property var initialProperties — it's weird and inefficient to have a declarative properties map that is only ever accessed in procedural code (onTriggered signal handler). It means that it keeps updating itself whenever any of bound object/properties change, and also means that it is a race condition between this Action's own onTriggered handler and possible other handlers in downstream code that may attempt to modify this map. Not to mention that it needs to actually keep that map in memory the whole time! A better solution would be to have an overridable method whose default implementation would return an empty map or null, like this:

  // PagePoolAction.qml:
  function getInitialProperties(): var {
      return null;
  }
  
  // app.qml
  footer: Kirigami.NavigationTabBar {
      actions: [
          Kirigami.PagePoolAction {
              function getInitialProperties(): var {
                  const props = new Map();
                  props.set("data", root.computationallyExpensiveCall(data.source));
                  return props;
              }
          }
      ]
  }

• All methods should have type hints.