PERF: reindex default fill_value dtype
- [x] closes #45857
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [x] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.

Default fill_value (np.nan) to match interleaved_dtype when possible to avoid upcasting and allow for block consolidation. 

Using the example from the OP:

```
import pandas as pd
import numpy as np

df = pd.concat([
    pd.DataFrame(np.zeros((1000, 1000), dtype='f4')),
], axis=1).reindex(columns=np.arange(5, 1005))
print(df._data.nblocks) 

df.values
print(df._data.nblocks)  # <- now consolidating

%timeit df.values
```

main:
```
2
2
789 µs ± 135 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops 
```

PR:
```
2
1
2.01 µs ± 48.8 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops
```

@jbrockmendel - any suggestions here? The test added in this PR is failing for certain builds. Unfortunately, I'm unable to reproduce the failures locally so I'm not sure where to start.  @lukemanley do you happen to be using a windows machine or 32bit build locally? There's a comment in NDFrame._reindex_with_indexers `# TODO: speed up on homogeneous DataFrame objects (see _reindex_multi)` that i think might be useful in these cases.  Could that be helpful? > do you happen to be using a windows machine or 32bit build locally?

Nope. I'm unable to reproduce those errors on mac or 64bit windows. 

> There's a comment in NDFrame._reindex_with_indexers # TODO: speed up on homogeneous DataFrame objects (see _reindex_multi) that i think might be useful in these cases. Could that be helpful?

I'll take a look, thanks.  I’m going to close this PR. I cannot reproduce the failures locally. I tried a few different things but was unsuccessful in identifying where the float64 dtype comes from. I do not see that behavior locally.