Fix ambiguous initialize_list arguments

[jagerman]

This removes the convert-from-arithemtic-scalar constructor of any_container added in #788 as it can result in ambiguous calls, as in:

    py::array_t<float>({ 1, 2 })

which could be intepreted as either of:

    py::array_t<float>(py::array_t<float>(1, 2))
    py::array_t<float>(py::detail::any_container({ 1, 2 }))

Removing the convert-from-arithmetic constructor reduces the number of implicit conversions, avoiding the ambiguity for array and array_t. This also re-adds the array/array_t constructors taking a scalar argument for backwards compatibility.

[jagerman]

@wjakob - I think this should fix the ambiguity issue; can you give it a try with your various (unmodified) projects to confirm?

(A related idea: it would be very useful to have some failure-allowed travis-ci builds that install pybind (without compiling the test suite since that's already done in the other builds), then clones a few open source pybind-using projects and tries to build and/or test them. It could help catching some backwards compatibility issues like this.)

[wjakob]

Thanks! I confirm that this PR fixes the issue.

Regarding your suggestion: I think that our test suite is actually pretty good; it's gotten increasingly rare that something slips through. Downsides of testing further projects are that this would likely consume quite a few extra cycles -- not so nice given that we're on the free tier of Travis CI. My impression is that the previous approach of leaving enough stabilization time to catch rare regressions before releases suffices, though we can certainly discuss this further.

[jagerman]

That's a good point, and given that we almost never remove things from the test suite, the coverage is probably pretty good.