Issue
- When there are too many resources to show in a list we enter `max` state
- When in max'd state we force the user to select filters to restrict the number of results (changing filters results in new https requests containing those filters)
- We persist the state of the list to local storage. This includes filters but does not include the `max` flag
- When the user re-vists the list after page refresh instead of fetching all resources we only fetch those applicable to the filter (which will be a small subset of all resources). As the `max` flag isn't there we assume we've fetched all resources. Any changes to the filter are then applied locally to the subset of resources... which won't contain any from the new filter

Fix
- Persist the list's `max` state such that when the list loads again all filter changes correctly result in http requests
- This needed a fix in the way we watch the filters for changes (we block this watch until all filters report as ready)
- Fix downside
  - Lists cannot ever leave the `max` state. All changes to filters will result in http requests. User would need to clear their local cache to reset the list (we have a button for this in the user's profile page)

Tested
- Different types of org/space filter setups
  - orgs with no spaces
  - orgs with some spaces under maxed, some over
- Different types of lists
- Tested with UI_LIST_ALLOW_LOAD_MAXED true (allow user to overrule maxed state and fetch everything)

Fix application of `maxed` lists following page refresh

Bump versions from 4.4.4 to 4.4.5, add to changelog