Normally we'd only need it in the case of scheduling a weakly cached build,
but to allow caching of failed builds we need to be able to distinguish
between cached successes and cached failures
for both strong and weak cache keys.

To allow other cache lookup codepaths to look up via the weak key
requires changes through the call stack to consult which key to use,
and cache invalidation of the saved state when it changes.

This just puts the metadata in place,
we're adding code paths to add failed builds later.

When we later add cached failures it needs to not treat them as successes.

This creates an artifact when element assembly fails too,
and if it's the right kind of exception uses the now-included install directory
similarly to if it had returned successfully.

If there's a failure during install the artifact contains any installed files,
but may contain nothing at all.

This flags up a failure and if run in an interactive prompt
permits the user to attempt a rebuild.

This allows the scheduler to move jobs from the current queue to the next.

As a result of this change later queues than the build queue
mustn't skip a cached failure, so the logic is specialised to build queues only.

Closes #76.

Store failed builds in the cache

Closes #76

See merge request !475

A project path is a path relative to a project directory.

A project path can not also refer to the parent directory in the first
path component, or point to symbolic links, fifos, sockets and
block/character devices.

The autotools example had to be copied over inside of the junction
example, as referring to a path outside of the project directory is
now disallowed.