Incorporating latest API changes

[mustberuss]

This is the remaining code to catch up with the current state of the API:

• paging by only primary and sometimes secondary key and applying the user's sort in R; deprecating the page and per_page search_pv() parameters; padding the patent_id's after value when patent_id is used as the sort field; exporting the padding function and adding after as a search_pv parameter for custom paging; removal of paging limits
• accepting group names in the field parameter (API's new shorthand); get_fields() returning group names as fields rather than fully qualifying (group.member notation) each member of the group
• unnesting and casting changes now that the endpoint names (singular, some nested) and returned entities (mostly plural) aren't interchangeable; dealing with the two endpoints that return rel_app_texts (from patent/rel_app_text and publication/rel_app_text)
• switching to httr2, httr says it's superseded: only changes necessary to keep it on CRAN will be made.
• there's an additional inclulde_pk boolean on get_fields() and encoded_url boolean on retrieve_linked_data()
• there is a new qry_fun in_range() that isn't strictly needed, it's not fronting anything in the API but would generate the tedious _and/_gte/_lte needed ex: qry_funs$in_range(patent_date = c("1976-01-01", "1983-02-28"))
• field name/endpoint name changes in the examples
• bug fix on posts when fields or sort wasn't specified
• bug fix when there was more than a primary sort
• bug fix to avoid a coercion warning

[crew102]

Are you OK with us removing the functionality of adding in additional fields to the query for situations where the user doesn't include that field in their field list? I think it's reasonable to assume that if a user is specifying a field as a sort field, they should have included that in the list of fields to fetch. It would make the code simpler and I think it's worth the tradeoff.