Fix resolution issues with aggregating projects.

[jmcclell]

Fixes #21

[sjrd]

Is there any guarantee that the one you request is always last?

[jmcclell]

@sjrd You'd probably need to direct that query to the SBT maintainers :) It's the observable behavior that I see in my own testing. Much like any output from SBT, it's possible a newer version could alter the output format.

One could attempt to parse the output, matching the project identifier in an attempt to make sure the appropriate path is collected? Might be a bit overkill?

Okay, did some digging. The SBT manual states

Note: aggregation will run the aggregated tasks in parallel and with no defined ordering between them.

I've not observed a case where the output order differed, but it sounds like some amount of parsing would be prudent. Let me take a stab at it.

[jmcclell]

@sjrd Baking the workaround directly in seems to be a reasonable approach, so I did that.

Attempting to parse quickly proves overly tricky -- too many edge cases with the difference between input and output of tasks re: implicit axes (e.g. "fastLinkJSOutput" and "root / fastLinkJSOutput" tasks come out as "Compile / fastLinkJSOutput")

I am unaware of any cases where setting aggregate on a key should fail. I also couldn't think of any use case for needing the aggregation to happen when attempting to retrieve the value.

Thoughts?