REF: `DataFrame.to_latex` directs to `Styler.to_latex`
Closes #41649.
A lot of the audit trail for the features to get this to work are documented in the issue. 

## For Reviewers

These are the key changes to note in **DataFrame.to_latex tests**

- The expected output remains as close as possible to the original, altering the arg input in `to_latex` to demonstrate the new combinations needed.
- No tests have been removed, and all pass with often minor alterations to the test formatting .
- `hrules=True` is added to all tests to get `\toprule \midrule \bottomrule`. This is a new option and the default in Styler is not to have these.
- `\cline` (for multirow) has gone. This feature is not implemented in Styler.
- `col_space` is gone, meaning there is not a nice console alignment of text. Of course the LaTeX rendering is unaffected by this, and when styling LaTeX commands are added this needs to be removed anyway.
- There are some nice new features added here, but all currently exists from Styler anyway, and that is where testing resides.

## Follow-Ups

- [ ] Make jinja2 a **hard dependency** (#43423) (this PR actually contains the jinja2 PR to help with tests passing)
- [ ] Deprecate all `pandas.options.display.latex` documenting the replacement `styler.latex` options instead.
- [ ] Remove all redundant code for python LatexFormatter.
- [ ] Reimplement cline? Im not a huge fan of this and I think it (maybe?) quite complicated to implement

## Revised Docs

![Screen Shot 2021-09-06 at 23 50 02](https://user-images.githubusercontent.com/24256554/132262289-da75546f-9aca-4938-b32b-12eb84377b25.png)
![Screen Shot 2021-09-06 at 23 50 20](https://user-images.githubusercontent.com/24256554/132262291-eca0003a-ca69-4079-8023-88c489d84034.png)
![Screen Shot 2021-09-06 at 23 50 32](https://user-images.githubusercontent.com/24256554/132262293-89d724d2-673b-4770-9924-0a7269b82b9e.png)
![Screen Shot 2021-09-06 at 23 50 44](https://user-images.githubusercontent.com/24256554/132262294-0e03da0d-5fbb-4101-90d5-5728fe1dfeb6.png)

This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this. This is now at a stage where it can be reviewed. If this requires jinja2 to work now as opposed to previously, would we need a deprecation cycle first? (Argument names also seem to be changed, but I'm not too familiar with this section of the code base, so idk whether the old args would still work)

This also probably needs a whatsnew. > If this requires jinja2 to work now as opposed to previously, would we need a deprecation cycle first? (Argument names also seem to be changed, but I'm not too familiar with this section of the code base, so idk whether the old args would still work)
> 
> This also probably needs a whatsnew.

What would the deprecation cycle look like, since this is a kind of an all or none change therefore:

 - a) we do nothing except warn users that the implementation will change? This doesn't seem to offer any benefit since the new implementation can't be tested by users?
 - b) we warn the implementation will change and offer a `DataFrame.to_html_test` method so that users can become accustomed to the new method before its officially added, still using the old.
 - c) we adopt the details contained in this PR whereby much of the implementation remains intact with warnings for the deprecations and what are the alternatives, but users will have to make changes.

I'm not completely convinced of the need for a deprecation cycle, other than whats included here, but interested in the opinions.

Currently the deprecated args just give warnings they are no longer used. It might be possible to squeeze **some** of them into the new format, however, e.g. old `bold_rows=True` triggers new `bold_header="both"` for example. > main question is why are we caring about any _new_ options at all here? personally i would make the existing options work (maybe with a deprecation warning if needed), and actually deprecate the entire function in place of `df.styler.to_latex()`

Yes OK I see your point. I will try a second proposal which attempts to reuse all the existing args and does not anything new args (since you are right: all available in styler), but adds a deprecation warning. > main question is why are we caring about any _new_ options at all here? personally i would make the existing options work (maybe with a deprecation warning if needed), and actually deprecate the entire function in place of `df.styler.to_latex()`

+1 on this.  Would this mean #43423 would be pushed backed to 2.0, if the current functionality is just being deprecated and not removed? > > main question is why are we caring about any _new_ options at all here? personally i would make the existing options work (maybe with a deprecation warning if needed), and actually deprecate the entire function in place of `df.styler.to_latex()`
> 
> +1 on this. Would this mean #43423 would be pushed backed to 2.0, if the current functionality is just being deprecated and not removed?

If we target 2.0 to use jinja2 for `to_latex` `to_html` and `to_string`, then perhaps the simplest thing to do for 1.4.0 is just add a FutureWarning and thats it? I thought this might be annoying for jupyter notebook users but Future warnings don't show up by default when rendering the cell, but do if the method is called directly (see below)

This would of course push the jinja2 dependency to 2.0 as well? And in 2.0 the major version change would probably allow me the backdrop to then overhaul these methods as per this PR?

Is this the preferred route - I'm happy to work more on this but prefer an agreed spec before engaging
![Screen Shot 2021-09-18 at 13 22 23](https://user-images.githubusercontent.com/24256554/133887102-ddafdcd4-fc87-412d-8a27-422f333c2abf.png)
 closing this temporarily in favour of #44411 