Pagination support for /users

[oguzkocer]

This PR adds strongly typed next_page_params & prev_page_params fields to the response types that supports pagination. The response types are generated by #[derive(WpDerivedRequest)], so here is a shortened example of how that looks:

#[derive(WpDerivedRequest)]
enum UsersRequest {
    #[contextual_paged(url = "/users", params = &UserListParams, output = Vec<crate::SparseUser>, filter_by = crate::SparseUserField)]
    List,
}

The above implementation will result in the following generated code:

pub struct UsersRequestListWithEditContextResponse {
    pub data: Vec<crate::UserWithEditContext>,
    pub header_map: std::sync::Arc<crate::request::WpNetworkHeaderMap>,
    pub next_page_params: Option<UserListParams>,
    pub prev_page_params: Option<UserListParams>,
}

Notice that there is now a new #[derive(WpDerivedRequest)] attribute: #[contextual_paged]. This attribute works exactly the same as #[contextual_get]. The only difference is #[contextual_paged] response types will have next_page_params & prev_page_params fields, but the #[contextual_get] doesn't.

Also notice that the type of next_page_params & prev_page_params are Option<UserListParams>. This is the params field that's passed in the #[contextual_paged] attribute.

---

WordPress endpoints that support pagination will have a header link with next & prev headers when it's appropriate. As far as I can tell, /users endpoint will include these headers if the per_page parameter is provided. So, at this time, the response for the default UserListParams will not include them. This issue will be handled in a separate PR.

The way this implementation works is by checking the next and prev header links for params types that support it. For a params type to support pagination, it needs to return true from its FromUrlQueryPairs::supports_pagination() implementation. All params type that implements this trait should return true for this function, except for the () type which is used as a marker to indicate pagination is not supported.

FromUrlQueryPairs trait is how we parse the header links into params type - using its from_url_query_pairs function implementation. There are a few helpers to do this, so its implementation for a params type is mostly straightforward. However, these helpers require the types used in a params type to implement std::str::FromStr or wp_api::OptionFromStr traits. For example, since UserListParams has pub who: Option<WpApiParamUsersWho> field, WpApiParamUsersWho has to implement the std::str::FromStr trait.

---

We now have AppendUrlQueryPairs & FromUrlQueryPairs traits to convert the params types to and from url query pairs. Since both of these implementations should use the same keys for the query pairs, a new enum UserListParamsField is added. This enum converts the field names for UserListParams into &str. It'd be easy to generate these field types from a proc macro, but for now they'll be hand rolled.

---

The PR includes unit tests to validate going from a UserListParams to query pairs and then parsing it back to UserListParams and compare the two. It also includes pagination Rust & Kotlin integration tests for /users endpoint.

There are also other unit & integration tests to validate the behavior changes to #[WpDerivedRequest].

[jkmassel]

I tested this from Swift and it worked great – the test coverage here is good, so I'm confident in the codegen stuff