DEPR: `Styler.where` possible deprecation
closes #40124 

Proposal to deprecate the method: `Styler.where`, since `Styler.applymap` and `Styler.where` are so similar in function, and return signatures, that it is almost confusing to have 2 methods for the same thing.

Note that `Styler.where` offers no advantage over `applymap` since internally it just restructures the callable and uses `applymap` itself:

```
def where(..):
    return self.applymap(lambda val: value if cond(val, **kwargs) else other, subset=subset)
```
i would actually deprecate .applymap, as its a non-vectorized version of .where (not that this matters for Styler generally).

ok can you separate out the bug fix and do the deprecation in a different PR? (where can discuss) > i would actually deprecate .applymap, as its a non-vectorized version of .where (not that this matters for Styler generally).
> 
> ok can you separate out the bug fix and do the deprecation in a different PR? (where can discuss)

my other PR #40845 fixes the bug. This one I left as the potential deprecation. `Styler.where` is not vectorized, it's effectively a one-liner invoking `applymap`. cc @pandas-dev/pandas-core any thoughts here To use `where` in order to accomplish `applymap` seems unnatural:

    df.where(cond=lambda _: True, some_style)

To use `applymap` to accomplish `where` seems natural:

    df.applymap(lambda x: some_style if cond(x) else other_style) > To use `where` in order to accomplish `applymap` seems unnatural:
> 
> ```
> df.where(cond=lambda _: True, some_style)
> ```
> 
> To use `applymap` to accomplish `where` seems natural:
> 
> ```
> df.applymap(lambda x: some_style if cond(x) else other_style)
> ```

I think I agree with this. As a user I always find myself having to stop and think what `where` actually does, on the other hand methods like `map`, `apply`, and `applymap` are more obvious. ok thanks, yeah no harm in deprecating