Feature: Improve select components

[JeanPaiva]

This PR changes how the posts selects works.

• Reduce the amount of first loaded posts from 100 to 10
• Does an extra request to fetch the selected values
• Upon search will fetch posts with the search value and persist the previous results
• Order posts by "id"

This affects Query loop "Parent", "Exclude Parent", "Include posts", "Exclude posts" and Dynamic data "Select source post".

There's the possibility to add pagination upon scroll, but we are limited by the API. We can, for example, increase the page number on each scroll fetching more posts, but the API does not support to make request with a number larger the the actual "page" count, so its required to us to know before hand how many pages the request has.

Currently, the only way to know the number of total pages on request is checking the "Header" of the request, but the core hooks seems to not have a way for us to use that information. Using our own implementation of fetching posts was also an option and could solve the pagination problem, but would require us to implement state caching so we don't re-fetch same requests many times thus requiring much more work than expected.

After testing, if everything is working fine as supposed to we must replicate this changes to all Terms selects.

[tomusborne]

@JeanPaiva Could we do a "Load More" button at the bottom of the list? I assume if we click the button and no results are found we can hide it?

[JeanPaiva]

@tomusborne we can have the button or even just load when user gets to the end of the list. The problem is requesting not existing page number, for example, https://example.com/wp-json/wp/v2/posts?page=2 if there's no page two the request will generate an console log error and using core hooks we can't even identify that to stop doing more requests.

[tomusborne]

And there's no way to catch the error and do something with it?

I think this should be targeted for release/1.6.0 so we have more time to test/improve it if possible.