Handle 'or' in versions in a primitive manner

[filmor]

The first constraint in a chain of "or"'d constraints is taken into
account, all others are ignored. That way, there is at least some
resolution happening, which can always be overridden via rebar.config.

[filmor]

@ferd @tsloughter Would something like this have any chance of getting merged? It sidesteps the whole "requirement vs version" and verl discussion by just using the first condition. This would allow me to progress on my rebar_mix attempt, while still being able to just force the required version.

[ferd]

Yeah I'd be willing to get an in-between patch where or is handled explicitly to at least reduce some amounts of glaring conflicts. I don't see a problem with that, particularly if it has tests.

[filmor]

Good, anything I should add or change before this can be merged? The failure on macOS was due to brew not getting updates, rerunning it is probably enough.

[ferd]

Yeah I think I'd like a test that runs on versions like 1.0.1-custom-or-label or 1.0.0 and shows that it doesn't see the or in the label as a split source. I think this will otherwise let people do weird stuff with version injection.

[filmor]

Finally got around to adding tests (and "fixing" the exact issue that you may have been hinting at ;)).

[filmor]

@ferd The only error here is the brew doctor call which, I think, should be made into a warning instead of failing the whole run.

[ferd]

Yep thanks for the edit, and yeah the brew thing is known breakage I need to look at. Merging this!