Convenience features for `NextcloudRequest.Builder`

Issue

The following setup for a NextcloudRequest is quite verbose:

final var parameters = Collections.singleton(new QueryParam("foo", "bar"));
final var nextcloudRequest = new NextcloudRequest.Builder()
    .setMethod("GET")
    .setParameter(parameters)
    .setUrl("/endpoint")
    .build();

Especially for beginners, we should try to minimize the necessary boilerplate code to perform an actual request.

Proposal

Automatically parse QueryParams from the given URL

We could parse the QueryParams from the given URL and add them to our Collection (just as if .setParameter() would have been called). A working sample implementation (in Kotlin) is already in the nextcloud-commons library available.

final var nextcloudRequest = new NextcloudRequest.Builder()
    .setMethod("GET")
    .setParameter(parameters)
    .setUrl("/endpoint?foo=bar")
    .build();

Default method property to GET

It is the most often used HTTP verb and a natural choice to be preset (of course with keeping the possibility to override it):

final var parameters = Collections.singleton(new QueryParam("foo", "bar"));
final var nextcloudRequest = new NextcloudRequest.Builder()
    .setParameter(parameters)
    .setUrl("/endpoint")
    .build();

Looking forward to some opinions 🙂
PS.: This issue has been split out of #266

Comienza por la implementación de NextcloudRequest.Builder e inspecciona cómo se almacenan setUrl, setParameter y el método HTTP antes de build(). Compara el análisis de la URL solicitado con el ejemplo de Kotlin enlazado y verifica después que se incluyan los parámetros de la URL, que GET sea el valor predeterminado y que un método seleccionado explícitamente siga funcionando.