ENH: Add support for min_count keyword for Resample and Groupby functions
- [x] closes #37768
- [x] closes #37821
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry

This would add support for the documented keyword ```min_count``. If we decide to move forward with this, we have to decide what to do in the following case:
```
df = DataFrame({"a": [1] * 3, "b": [np.nan] * 3})
result = df.groupby("a").func(min_count=0)
```

``first`` and ``last`` return ``0.0`` which is fine I think and consistent with ``sum``, but ``min`` returns ``inf`` while ``max`` returns ``-inf``.

Default parameter is set to ``1`` to avoid backwards incompatible changes. We should keep this at least until 2.0

If we decide to not implement ``min_count`` here, we should adjust the docs and the function signatures for the groupby functions.

cc @rhshadrach 
Thanks for the PR @phofl. It seems to me that first, last, min, and max should all return nan even when `min_count` is 0. Sum behaves differently because the empty sum is 0 (likewise, the empty product is 1). > Default parameter is set to 1 to avoid backwards incompatible changes. We should keep this at least until 2.0

Do you perhaps mean -1? Otherwise, I don't follow. My 2 cents: min_count=0 is the same as not specifying a min_count. Min_count of x says you need to have at least x non-nan values in the bin to show a result, otherwise show nan. If you have a min_count of 0 isnt that like saying show me the sum, first etc regardless how many nans are there? Maybe I am missing something? 

But while it is important to decide what min_count=0 should show it is less important for the implementation, you would not specify that imo, because as mentioned it is like not specifying it. I am ok with any decision. cc @rhshadrach  When we want to return nan in this case, we can keep -1 as default. lgtm. ping on green (resolved conflict) @jreback greenish. Failure is unrelated thanks @phofl 