Feature Request

Is your feature request related to a problem? Please describe.
The Navigation components traverse the entire content tree (within the bounds of the max depth) immediately when the first level of the navigation items are requested. This might be an extremely large structure which may take a non-trivial amount of time to evaluate.

Normally, in the context of how this information is used by the front-end Navigation components, this isn't a big deal because all of those list items are going to be displayed anyway. However, if a user wants to add additional logic in order to prune or modify the list, and they do so by using the sling model delegation pattern, there is no way for them to escape the cost of constructing the entire navigation tree, even if they don't use it all.

Describe the solution you'd like
In the Navigation models, when constructing Navigation Items, the items are a List, requiring that all the children are previously known and constructed. I propose to change this to a Supplier<NavigationItem>, so that how to get the child items is known, but they are not evaluated until/unless required.

This would not effect the Navigation interface, and so would be an invisible change to consumers of Navigation/NavigationItems.
This is just a minor optimization to the backend that would have a trivial impact in normal use, but potentially a profound performance impact in very niche use cases.

Are there alternatives?
Another related feature that might help would be if there was a Sling Model that would supply the Filter<Page>.
Such a model would allow clients to implement just the filtering logic for customizing which NavigationItems are included, without having to rewrite the entire Navigation model. In the absence of such a model, the default new PageFilter() would be used instead (fallback to current functionality).

Documentation
This wouldn't really require any change to the documentation, as it is just a minor back-end optimization.