Really disable auto-vectorization.

The previous patch was insufficient. Craig Topper explains:

  -fno-vectorize only disables the loop vectorizer

  -fno-slp-vectorize only disables the SLP vectorizer

  The backend can also use vector instructions for memcpy/memset or
  combining multiple scalar loads and/or stores. That is independent
  of -fno-vectorize.

  -mllvm -vector-bits-min=0 will disable any use of fixed vectors. And
  will make attribute(vector_size) get scalarized.

  -mno-implicit-float will disable both vectorizers and
  prevent the backend for using vectors for memcpy/memset
  oor multiple scalar loads/stores. It will not affect
  attribute(vector_size). -mno-implicit-float also prevents scalar
  floating point instructions from being used for anything that didn’t
  use float/double/_Float16/etc. type in source, but I don’t think that
  happens on RISC-V today. 32-bit X86 can use a 64-bit x87 FP load as an
  atomic load for uint64_t, for example. Basically -mno-implicit-float
  is supposed to prevent the compiler from using FP or vectors when the
  source doesn’t explicitly use FP or vectors.

So -mno-implicit-float was what we were actually looking for here. I've
done a clean build with this change, and see only the expected
(hand-written assembler) vector code in bionic, and the ART
ClassLinker::LoadClass() issue is gone too. As far as I can tell, the
remaining vector code is all deliberate in that sense.

We may still end up back here again, to change "gcv" to "gc", but that
still requires some code changes just to build, and still makes it less
obvious that this is just a temporary workaround for a qemu bug
(specifically https://gitlab.com/qemu-project/qemu/-/issues/1976).

Bug: http://b/320416684
Test: objdump
Change-Id: Ibd104e4289d6d1aaf441efa0440fedc90e3da29a