Refactor: BIDS functionality

[AlanKuurstra]

No description provided.

[AlanKuurstra]

need a better system for determining if a bids derivatives is expected when using derivatives for caching.

for instance, if the user employs the cmdline flag to skip motion correction, then the mc transform is not supplied to the outputnode and the derivative is not created. And in this case, the mc transfrom derivative should not be expected when doing a derivatives cache check for the pipeline.

or what if the user does not want to perform a brain extraction - that derivative should not be required in the derivatives folder.

[mklassen]

Checking whether the output node has a connection to the attribute from which the derivative is derived is likely the best way to determine if the derivate should exist.

[AlanKuurstra]

@mklassen
Consider workflow A with an optional output (perhaps a masking operation is optional and whether a mask is output depends on user commandline input.)

Now consider an owner workflow B which uses A. B does not override A's commandline options and therefore does not know if A will or will not have something hooked up to outputnode.mask. However, B figures that a mask - if it is calculated - is useful and so it hooks up A.outputnode.mask to B.outputnode.mask.

Now we decide to extend B into a BIDS workflow and want B.outputnode.mask to be hooked up to a BIDS derivative. In this case, we cannot check B's outpnode connections to know if a mask is actually being output as a derivative.

I can see 2 ways forward:

1. the user is responsbile that before they hook up the result from a subworkflow to their own outputnode, they must check that the subworkflow has indeed made a connection. This seems cumbersome - especially in cases where a workflow is being designed without BIDs in mind. Perhaps B was designed without BIDS in mind. Later somebody wants to create C which uses B but also wants to be extend C to a BIDS worfklow. They have no way to know if B was respecting the rule that it should check A before hooking things up to its outputnode.

2. we can introduce some logic to traverse through trees of connections to see if there ever was a subworkflow outputnode that was not connected. I'm not sure how expensive this is.

[mklassen]

For now ignore the issue. The worst that can happen is the user recomputes something unnecessarily. I think dealing with #17 will alleviate a lot of these types of issues and make the design a lot simpler. So leave the issue for v2