[WIP] Resolve dependencies before build_id can be computed

[pelson]

This looks like a long PR, but the majority is really the addition of tests and test-infrastructure.

My aim in this PR is to facilitate a more natural pinning scheme *. Exactly how the pinning looks is academic to this PR (though I had to get off the fence and implemented something) - to be able to support pinning without users pre-defining the versions in (environment) variables before calling conda-build it is necessary to resolve which distributions are available to build against. The existing environment variables have been preserved as hints to the solver to determine which distributions are wanted, but they do not directly feed into the pinned down version in the resulting built distribution.

The main implication of this change is that one cannot compute the build_id of a distribution until after the build dependencies have been resolved.

With the resolved information so readily available, it would have been much easier for @ilanschnell to implement the usecase targeted with #741.

This PR is still a work in progress, but I'd really value some input from @ilanschnell / @msarahan / @stuarteberg + others as to whether this is going in the right direction, or whether you want to apply the brakes. @kalefranz may be particularly interested in the test strategy involved.

The pinning mechanism invoked in this PR is done at build-time, rather than parse time. There are implications for doing the pinning at parse time, but the changes here do not preclude that being chosen at a future point. Essentially, I've implemented a pretty rudimentary scheme which looks like:

requirements:
  build:
    - python
    - proj4
  run:
    - python
    - proj4
  pin_from_build:
     - python x.x.*
     - proj4 x.x.x.*

I'm not especially tied to this solution, and it is completely possible to re-use the x.x scheme already implemented - it just made sense to separate the concerns when I was doing it (explicit is better than implicit).

* There has been plenty of discussion about how pinning should take place. Those conversations have value and should continue in #728 and #650.

[pelson]

@kalefranz - I know you are extremely busy, but this PR represents a huge step forwards in conda-build's ability to accommodate maintainable recipes - it would be really valuable to get your time on a preliminary review of it.

Once that is done, I will rebase and ensure that everything is spick and span for a final review.

[pelson]

Think I may want to add a test which pins something which wasn't a build dependency.

[pelson]

Did that in test_pin_non_build_dep

[stuarteberg]

The issue you're addressing here is an important one. This PR and #848 have overlapping concerns, so we should consider the pros/cons of each, and decide if there is any advantage to unifying the ideas in each.

[kalefranz]

@pelson et al., devoting all of today to this and related issues. All conda-build. Up to now have spent the majority of my available cycles on conda, with the result being from going to over 40 open PRs to less than 10. conda-build will take more time, but the pinning issues seem to be the most urgent and are at the top of the list :)

[msarahan]

@pelson, is #848 + #923 adequate to meet the needs you present here?

[msarahan]

Closing this to consolidate discussion to #966 where I'm trying to consolidate implementation of these ideas. Thank you everyone for your contributions to this discussion.