[NFC][SROA] Clean up rewritePartition type selection process (#169106)

This change reverts
https://github.com/llvm/llvm-project/commit/257251247a267c3fa30fdeef17ffa4987d8a52e5,
which landed on Aug 8, 2022. This change addressed the problem that if
you have IR that looks something like:

```
%alloca = alloca <4 x float>
store <4 x float> %data, ptr %alloca
%load = load half, ptr %alloca
```

`getCommonType` would return `<4 x float>` because the `load half` isn't
to the entire partition, so we skip the first `getTypePartition` check.
https://github.com/llvm/llvm-project/commit/257251247a267c3fa30fdeef17ffa4987d8a52e5
added a later check that sees that `<4 x float>` is not vector
promotable because of the `load half`, and then calls
`getTypePartition`, which changes the `sliceTy` to `< 8 x half>`, which
is vector promotable because the store can be changed to `store <8 x
half>`. So we set the `sliceTy` to `<8 x half>`, we can promote the
alloca, and everyone is happy.

This code became unnecessary after
https://github.com/llvm/llvm-project/commit/529eafd9beff233ba8debfc73e0b5c04cac36835,
which landed ~3 months later, which fixes the issue in a different way.
`isVectorPromotionViable` was already smart enough to try `<8 x half>`
as a type candidate because it sees the `load half`. However, this
candidate didn't work because it conflicts with `store <4 x float>`.
This commit added logic to try integer-ifying candidates if there is no
common type. So the `<8 x half>` candidate gets converted to `<8 x
i16>`, which works because we can convert the alloca to `alloca <8 x
i16>` and the load to `load i16`, allowing promotion.

After
https://github.com/llvm/llvm-project/commit/529eafd9beff233ba8debfc73e0b5c04cac36835,
the original commit is pointless. It tries to refine the `SliceTy`, but
if `isVectorPromotionViable` succeeds, it returns a new type to use and
we will ignore the `SliceTy`.

This change is my first patch to try to simplify the type selection
process in rewritePartition. I had some other ideas that I tried in
https://github.com/llvm/llvm-project/pull/167771 and
https://github.com/llvm/llvm-project/pull/168796, but they need
refinement.