Uncacheable results not invalidated without new RunId

[stuhood]

The --loop flag uses a new RunId on each iteration, but until #15415, the BSP server code did not. That should have been fine: while the BSP server executes work for side-effects, it is a single long Session, and so it can safely assume that its side-effects with the .pants.d/bsp directory have not been cleared out from under it. Thus: dirtying of nodes should be sufficient: there is no need to force re-running for side-effects.

But for some reason, unless a new RunId is used, failed FallibleClasspathEntrys (which are cacheable=False when they fail) are not invalidated.

The workaround was to use a new RunId per BSP request. But this should be investigated, since it should not be necessary.