Stack elements cannot be build-only dependencies, as this would defeat
the purpose of using stack elements in order to directly build-depend on
them.

Stack element dependencies must all be built in order to build depend
on them, and as such we gain no build parallelism by allowing runtime-only
dependencies on stack elements. Declaring a runtime-only dependency on
a stack element as a whole might still be useful, but still requires the
entire stack to be built at the time we need that stack.

Instead, it is more useful to ensure that a stack element is a logical
group of all dependencies, including runtime dependencies, such that we
can guarantee cache key alignment with all stack dependencies.

This allows for stronger reliability in commands such as
`bst artifact checkout`, which can now reliably download and checkout
a fully built stack as a result, without any uncertainty about possible
runtime-only dependencies which might exist in the project where that
artifact was created.

This consequently closes #1075

This also fixes the following tests such that the no longer
require build-depends or runtime-depends to work in stack elements:

 * tests/frontend/default_target.py: Was not necessary to check results of show,
   these stacks were set to runtime-depends so that they would have the same
   buildable state as their dependencies when shown.

 * tests/format/dependencies.py: tests/frontend/pull.py, test/frontend/show.py,
   tests/integration/compose.py:
   These tests were using specific build/runtime dependencies in stacks, but
   for no particular reason.

As a rule, throughout the codebase we should not be using internal
ProvenanceInformation objects in our APIs, but rather Node objects.

This is because ProvenanceInformation is generated on the fly from
a Node object, and it is needlessly expensive to instantiate one before
it is absolutely needed.

This patch unilaterally fixes the codebase to pass `provenance_node`
Node objects around as arguments rather than `provenance` ProvenanceInformation
objects.

Plugins must not access public data of build dependencies in
`integrate()` as the build dependencies are not guaranteed to be cached
at that stage.

This combines integration commands of the sole build dependency and the
filter element itself at time of assembly instead of integration.

Refactored this to remove unneeded complexity in the code base,
as described here:

  https://lists.apache.org/thread.html/r4b9517742433f07c79379ba5b67932cfe997c1e64965a9f1a2b613fc%40%3Cdev.buildstream.apache.org%3E

Changes:

  * source.py: Added private Source._cache_directory() context manager

    We also move the assertion about nodes which are safe to write to
    a bit lower in Source._set_ref(), as this was unnecessarily early.

    When tracking a workspace, the ref will be none and will turn out
    to be none afterwards, it is not a problem that a workspace's node
    is a synthetic one, as tracking will never affect it.

  * local plugin: Implement get_unique_key() and stage() using
    the new context manager in order to optimize staging and
    cache key calculations here.

  * workspace plugin: Implement get_unique_key() and stage() using
    the new context manager in order to optimize staging and
    cache key calculations here.

  * trackqueue.py: No special casing with Source._is_trackable()

Instead of relying on Element.search(), use Element.configure_dependencies() to
configure the layout.

Summary of changes:

  * scriptelement.py:

    Change ScriptElement.layout_add() API to take an Element instead of an element name,
    this is now not optional (one cannot specify a `None` element).

    This is an API breaking change

  * plugins/elements/script.py:

    Implement Element.configure_dependencies() in order to call ScriptElement.layout_add().

    This is a breaking YAML format change.

  * tests/integration: Script integration tests updated to use the new YAML format

  * tests/cachekey: Updated for `script` element changes

Staging artifacts at Element.assemble() time is now illegal

It will now be illegal to call Element.stage_dependency_artifacts() outside
of the Element.stage() abstract method.

This is a large breaking change, a summary of the changes are that:

  * The Scope type is now private, since Element plugins do not have
    the choice to view any other scopes.

  * Element.dependencies() API change

    Now it accepts a "selection" (sequence) of dependency elements, so
    that Element.dependencies() can iterate over a collection of dependencies,
    ensuring that we iterate over every element only once even when we
    need to iterate over multiple element's dependencies.

    The old API is moved to Element._dependencies() and still used internally.

  * Element.stage_dependency_artifacts() API change

    This gets the same treatment as Element.dependencies(), and the old
    API is also preserved as Element._stage_dependency_artifacts(), so
    that the CLI can stage things for `bst artifact checkout` and such.

  * Element.search() API change

    The Scope argument is removed, and the old API is preserved as
    Element._search() temporarily, until we can remove this completely.

This prepares the ground for policing the dependencies which are visible
to an Element plugin, such that plugins are only allowed to see the
elements in their Scope.BUILD scope, even if they call Element.dependencies()
on a dependency.

This commit does the following:

  * Element.dependencies() is now a user facing frontend which yields
    ElementProxy elements instead of Elements.

  * Various core codepaths have been updated to call the internal
    Element._dependencies() codepath which still returns Elements.