Improve, organize and consolidate API contract types

[acelaya]

The API contract exposed by this library is sometimes a bit inconsistent.

Try to re-organize it, making it clear what are the types for stuff returned by the API client methods, types for their params, and smaller sub-types which are usually part of them.

One option would be that the first two used the Request and Response suffixes, but that would couple them with the underlying HTTP layer, when in some cases they don't match 1:1

[acelaya]

The final decision is to use this wording: ...Params or ...Data for the arguments representing information being passed to the API, ...List for objects representing the result of a method returning a list of entities, ...Result for methods which perform a mutation (delete, update, etc) and return a type which is not an entity, and simply the entity name for methods returning one entity, both when reading and mutating.

Some examples:

• listShortUrls: The argument being passed is named ShlinkShortUrlsListParams, and it returns ShlinkShortUrlsList.
• createShortUrl: The argument is called ShlinkCreateShortUrlData and it returns ShlinkShortUrl.
• updateShortUrl: The argument is called ShlinkEditShortUrlData and it returns ShlinkShortUrl.
• getTagVisits: The argument is called ShlinkVisitsParams and it returns ShlinkVisitsList.
• getVisitsOverview: Returns ShlinkVisitsOverview.
• deleteShortUrlVisits: Returns ShlinkDeleteVisitsResult.

We will also try to avoid HTTP-related terminology, like query, body, request or response.

And finally, we will not expose as API contract types which are only internally used by the ShlinkApiClient implementation as intermediary types.