Update to upstream version '0.0.63'
with Debian dir 279c24fac8517e2a8272d9494793afe688b4d950

(pairing with @vlorentz)

Related to T2310

Update to upstream version '0.0.62'
with Debian dir b55f8a89978085d75b15a56406a3b3edd1fc2dc9

These are expected to be bytes, not str.

this does not work in the general case since there is no (recursive)
convertion of objects used as model object initialization.

We can only check when using the from_dict() factory.

for better clarity on the code author's intention.

it was still here for bw-compat but should not be necessary any more.

this function does not need to be a local function of the to_dict namespace.

Update to upstream version '0.0.60'
with Debian dir e539ea7a60cb91c2d7ac920492493b9cdf43fc33

This will allow deduplicating code across loaders.

This generates more realistic contents and avoids spurious HashCollisions when
generating a set of objects using these hypothesis strategies, at the cost of
slightly worse "boundary checking" (i.e. we won't check contents with a length >
4096 bytes).

This lets us generate Content objects directly from a bytestring, with the
proper set of hashes auto-generated from the contents.

Update to upstream version '0.0.59'
with Debian dir b29a4e120d6f24180eb5e25a7728c43d443c41b7

Update to upstream version '0.0.57'
with Debian dir b6fefac634efaca283f481b553074b3c49c16e6e

Required by loaders, when they can't parse the fullname.

Will be used by loaders.

It just makes more sense that way.

eg. before this change, all leafs would be equal to each other.

They will be used by loaders, so they can deal only with
model objects, instead of having to do the same conversion themselves.

This removes the `data` and `save_path` arguments of `from_file` and
`from_disk`, as data loading is always deferred from now on.
To access it, users are now expected to either open the data files
themselves, or us `.to_model().with_data()`.

Regular files were created, as the 'mode' argument of os.mknod was missing.
However, creating devices requires root; so we can't reasonably do that in
tests.

Instead, we're using /dev/null instead of creating one.
And while we're at it, let's also use /dev/zero (which, if not handled
properly, will result in an infinite read).