BUG/ENH: `Styler.format()` always inherits from `.set_na_rep()`
- [X] closes #40032 
- [X] tests added: `test_display_format_subset_interaction`: why: see below.
- [X] tests removed: `test_format_bad_na_rep`: why: `na_rep` works if not string in some cases - changed to duck-typing.
- [X] tests lefts unchanged that pass: `test_display_format`, `test_display_set_precision`, `test_format_subset`, `test_display_dict`
- [X] tests expanded: `test_display_format_raises`
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [ ] whatsnew entry

The issue is that there are currently two competing methods in `Styler` for missing value represenatation: 

  - `.set_na_rep('x')` and
  -  `.format(na_rep='y')`. 

The two do not interact well together dynamically. This PR brings the `format wrapping` into the class so that `format` can be updated and inherit values in `set_na_rep` after it has been called. The image below highlights the impact this PR has and the added test replicates this pattern:

![Screen Shot 2021-02-25 at 20 38 45](https://user-images.githubusercontent.com/24256554/109210160-bfbf5600-77ac-11eb-8be7-8938d80f4ce6.png)

Also at the bottom here, we add a `KeyError` to remove the ambiguity between what happens when a dict is provided with a column Key that is not specifically included within the provided `subset` slice.

> .set_na_rep('x') and
.format(na_rep='y').

if there are 2 let's deprecate one. we use `.format()` everywhere else, I don't really see having a specific method na rep as all that useful (we *also* have set_precision as well).

we need one canoncial way to do things. try not to mix bug fixes with api changes in a single pr. keep them as focused as possible. @jreback I agree somewhat that maybe multiple different `set_na_rep` and `set_precision` and `format` methods are not ideal and maybe incorporating everything to a format function is preferable. I've never suggested a deprecation previously (and all of these are legacy decisions from my perspective) but am happy to work on a solution otherwise, if you think thats better. I think the PR above is better both in terms of API and code maintenance. Do close this PR if you agree. 