test_api: highlight insertion_dates issue
api/get: avoid a useless computation when the series is remote

The `infer_freq` business is in this case handled by the remote side.
changelog: prepare news for the upcoming 0.20 release
testutil/make_tsx: allow to specify remote sources
api/get: have an `inferred_freq` parameter

This will reindex the series based in its inferred frequency.

This can be helpful to visualize missing data on a series with an
expected regular grnularity.
http/client: provide the oauth2 `pkce` flow
http/update: correctly handle the json path for naive series
http/util: use simplejson to correctly handle the NaN -> null translation
test/http/get: exhibit a non-conform json output

Turns out the Python json packages is non conforming.
http/server/update: allow to specify a time zone for your json
http/server/get: allow to specify a time zone for your json
http/server: in the json path, emit iso8601 timestamps in UTC with offsets rather than Z

We want to allow exposing the stamps in non-utc zones, and this is a
first necessary step. We are losing a bit of speed because of the
abandonment of pandas .to_json, but that's unavoidable.
tsio/register_basket: allow updating a basket definition
api/register_basket: show that we cannot update a basket
api/basket: better docstring
http/client: provide initial support for (machine-to-machine) oauth support

PKCE might be useful too.
cli/shell: let the magic operate

We want this tsa object to have the most specific available
handler (from a tsio module).
api.timeseries() will do the lookup automatically now.
http/client: do not turn naive dates into non-naive ones in utc
http/update: fix the update for real-world situations (json input)

We believe to have seen a discrepancy between
the webtest .patch behaviour and real world
patching. That should be investigated later.
Meanwhile, we will live with a 2-ways path for
the json update case.
http: introduce a permissioning system

There are several aspects to that:
* identification, that will be provided through an oauth2 wsgi middleware
* assignation of identified users to roles
* the "admin" + "rw" + "ro" + "guest" model.

Admin is supposed to be able to do anything.

The "nosecurity" wsgi middleware allows the app to run
as if there was no security.

"rw" and "ro" means respectively:
* a user that can read and write
* a user that can only read stuff

As for "guest" it's simply some identified person that has no assigned
role (yet).