PERF: Use fastpath for accessing option value in internals
Related to https://github.com/pandas-dev/pandas/issues/49729

Accessing an option value is in general quite fast, but when it is in code that is called repeatedly in a for loop, it still adds up it seems. 

Using the example from https://github.com/pandas-dev/pandas/issues/49729:

```python
import pandas as pd

def foo(df):
    for idx in df.index:
        df.at[idx, "bar"] = 3

df = pd.DataFrame(range(10000))
df["bar"] = 0

%timeit foo(df)
# 442 ms ± 16.1 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)  <-- main
# 316 ms ± 10.9 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)  <-- PR
```

I think this should be a safe way to access the option (but will add a test that ensures you can switch back and forth with CoW within a session).

Are we OK with this pattern? 

- [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.
- [x] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature. -> added in https://github.com/pandas-dev/pandas/pull/49772

hmm at one point we had a code check that checked for private imports.  guess that got lost somewhere along the way Curious if you've looked at making `get_option` a class and using `__slots__` instead for this? Seems like it would be the idiomatic approach to speeding up attribute access @WillAyd you mean the `DictWrapper` class that `get_option`/`options` uses? That is currently using a dynamic `__getattr__` to look up attributes in a global dictionary that actually stores the option values. 
What you suggest might be an option (but not directly an idea, didn't look into that), but that seems a bigger change in the internals of the options machinery. While what I am doing here is just using the fact that the current options internals is just a plain dictionary.  Best Practices-wise, the best-case would be to try to optimize get_option.  Next-best would be to make _global_config public-for-inernal-usage and canonize this as how we do option checks within pandas > best-cast would be to try to optimize get_option

That would require a change of (or addition to) how `get_option` works, I think. Currently that takes a string (eg `get_option("mode.copy_on_write")`), and thus that requires parsing the string, and also has some overhead. 

It's easy to rename `_global_config` to `global_config` (its module is already private) if that is preferred. yah even if we did optimize get_option a dict lookup will always be way faster