Need better messaging about workspaced junctions

Background

As reflected by my silly panic which resulted in filing #978 (closed), it can be quite easy to not be aware that you are working with an active workspace on a junction element.

Regular (non-junction) elements do not have the same problems, because:

  • At least whenever we start a session we display which elements in the pipeline have open workspaces
    • We don't show the junctions in the regular bst show codepaths which construct the pipeline summary, so we don't see these at session start
  • Parse/load errors cannot originate from inside a workspace unless it is a workspace of a junction

When load errors start happening because of a ref mismatch of a subproject, i.e. the subproject is not what you expect it to be, then you have to remember that you had a workspace open on the junction element.

Task description

  • Display active junctions beside the pipeline summary at session start

    This should just be done anyway, this is important information about a session and it's currently missing.

    Using the same codepaths as we use to display other elements will ensure that open workspaces will be indicated.

  • Enhance provenance to specify open workspaces

    Whenever a LoadError is raised, the provenance of the error should indicate that it's project is junctioned.

    Currently provenance only specifies the full element name including it's junction with junction.bst:element.bst colon notation, in the case that junction.bst has an open workspace, it will be useful to the user to indicate that, probably by specifying the path to the open workspace.

  • Enhance missing file errors to specify open workspaces

    The errors which say: "element.bst was not found in project referred to by junction.bst", should specify the junction's workspace path if the junction has an open workspace

Edited by Tristan Van Berkom