Abstract away inconsistency of empty results #17
Description
Currently the API returns null for some query endpoints where no results/matches exist, and for others it returns []. This can't be changed for backwards-compatibility reasons (see ideal-postcodes/postcodes.io#319).
However it makes sense in the context of this client to abstract that away and handle empties in a more predictable way (i.e. always returning an empty IEnumerable<T>). This will be more consistent for devs using this client library. This will be a backwards-incompatible change, so needs to tie to v1.x.
The ability to opt out of normalising empty results and back into API-consistent behaviour (3a/3b in the linked discussion, where results will come back as null where the API gives that) should probably also be added.