PERF: get_dummies create array of 0/1s with appropriate layout for internals
This ensures that the 2D ndarray that is created in `get_dummies` for a single column is directly in the "right" layout as the internals prefer it (column-major, so it's row-major in the transposed Block.values).

For ArrayManager, this gives a speed-up for `get_dummies` itself (because we still copy the arrays to ensure proper contiguous memory layout for each column, currently):

```
In [7]: %timeit pd.get_dummies(s, sparse=False)
23.2 ms ± 1.16 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)  <-- master
16.6 ms ± 689 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)  <-- PR
```

For the current BlockManager, it makes the actual get_dummies a bit slower, but can make a follow-up operation actually faster (where a copy, or consolidation, or a reduction, or .. would happen):

```
In [4]: %timeit pd.get_dummies(s, sparse=False)
10.7 ms ± 397 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)  <-- master
14.2 ms ± 713 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)  <-- PR

In [5]: %timeit pd.get_dummies(s, sparse=False).copy()
22.3 ms ± 260 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)  <-- master
17.8 ms ± 1.92 ms per loop (mean ± std. dev. of 7 runs, 100 loops each)  <-- PR
```

The timing is from the following example taken from the `frame_methods.py::GetDummies` ASV case:

```
import string

categories = list(string.ascii_letters[:12])
s = pd.Series(
    np.random.choice(categories, size=1000000),
    dtype=pd.CategoricalDtype(categories),
)
```

So it makes the actual `get_dummies` a bit slower for the BlockManager, and thus I could also explicitly only do this for the ArrayManager. But since it improves follow-up operations, I think it can actually be beneficial overall for BlockManager as well. But either is fine for me.