Detect ARMv7 CPUs without NEON extensions and treat as ARMv6

[sourcefrog]

Fixes /issues/587

[sourcefrog]

NB I don't have any other ARM machines on which I could test this.

[sourcefrog]

AppVeyor failure seems like an unrelated network error

https://ci.appveyor.com/project/brson/rustup-rs/build/1.0.401/job/t8lswqjhwcxg3020

[brson]

Thanks for the investigation and the patch @sourcefrog!

@alexcrichton and @japaric what do you think of this? Seems like something's wrong with our target defs.

[sourcefrog]

Hi brson, are you suggesting maybe you instead want to change the ARMv7 build to work without NEON? That would be another option. Or, you could have a separate build for ARMv7+NEON vs without.

I don't know how much of a boost use of NEON gives to Rust performance, or how common CPUs with and without it are.

[alexcrichton]

This seems like a fine patch to merge for now at least (to fix the target detection). I feel like any decision we make on the ARM target we'll eventually get wrong (unless we ship everyone ARMv5 compatible code), so I'm not sure if it's a strong indicator to change the target just yet.

[brson]

@sourcefrog oh I wasn't suggesting anything in particular. Getting toolchains to support the wide variety of arm configs is difficult and I just wanted confirmation from folks who are more familiar. Thanks again.

[japaric]

For the record: the topic of Scaleway, ARMv7 and NEON has come up before in the users forum. The TL;DR is:

• The common case is ARMv7 with NEON support. Scaleway seems to be an outlier here.
• If you have an ARMv7 processor without NEON, you should use the arm-unknown-linux-gnueabihf target (what this PR does!) because there's not much difference (codegen wise) between that target and the (non existent) armv7-unknown-linux-gnueabihf with NEON disabled.