BUG: datetime rolling min/max segfaults when closed=left (#21704)
User reported that `df.rolling(to_offset('3D'), closed='left').max()`
segfaults when df has a datetime index. The bug was in PR #19549. In
that PR, in https://github.com/pandas-dev/pandas/blame/master/pandas/_libs/window.pyx#L1268
`i` is initialized to `endi[0]`, which is 0 when `closed=left`.
So in the next line when it tries to set `output[i-1]` it goes out of bounds.
In addition, there are 2 more bugs in the `roll_min_max` code.
The second bug is that for variable size windows, the `nobs` is never updated
when elements leave the window. The third bug is at the end of the fixed
window where all output elements up to `minp` are initialized to 0 if
the input is not float.

This PR fixes all three of the aforementioned bugs, at the cost of casting the
output array to floating point even if the input is integer. This is less
than ideal if the output has no NaNs, but is still consistent with roll_sum
behavior.

- [x] closes #21704
- [x] tests added / passed
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry

Hello @changhiskhan! Thanks for updating the PR.



Cheers ! There are no PEP8 issues in this Pull Request. :beers: 

##### Comment last updated on July 13, 2018 at 05:02 Hours UTC # [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/21853?src=pr&el=h1) Report
> Merging [#21853](https://codecov.io/gh/pandas-dev/pandas/pull/21853?src=pr&el=desc) into [master](https://codecov.io/gh/pandas-dev/pandas/commit/365eac4d27353693a2b758c87fc4bceabb74817f?src=pr&el=desc) will **not change** coverage.
> The diff coverage is `n/a`.

[![Impacted file tree graph](https://codecov.io/gh/pandas-dev/pandas/pull/21853/graphs/tree.svg?width=650&height=150&src=pr&token=eZ4WkYLtcO)](https://codecov.io/gh/pandas-dev/pandas/pull/21853?src=pr&el=tree)

```diff
@@           Coverage Diff           @@
##           master   #21853   +/-   ##
=======================================
  Coverage   91.91%   91.91%           
=======================================
  Files         164      164           
  Lines       49992    49992           
=======================================
  Hits        45951    45951           
  Misses       4041     4041
```

| Flag | Coverage Δ | |
|---|---|---|
| #multiple | `90.3% <ø> (ø)` | :arrow_up: |
| #single | `42.16% <ø> (ø)` | :arrow_up: |


------

[Continue to review full report at Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/21853?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/21853?src=pr&el=footer). Last update [365eac4...7b839e5](https://codecov.io/gh/pandas-dev/pandas/pull/21853?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
 Not sure why the linter is failing on the travis-ci build. I updated my feature branch with E704 issues, and runnning ci/lint.sh locally passes just fine... ack, now it's reporting the travis-ci has passed. I guess it just didn't update yet after i pushed @jreback this looks about ready, but I don't know this part of the code that well. Piggy-backing off this PR for a pandas-dev question.
When I run the unit tests locally, I get a few locale related failures that I don't see on CI. e.g., `pandas/tests/series/test_datetime_values.py:305:`
Shows:

```
../../anaconda3/lib/python3.6/locale.py:581: in getlocale
    return _parse_localename(localename)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

**localename = 'en_IL'**
```

I'm not even sure where the "en_IL" is coming from:

```
(base) chang@changhispad ~/code/pandas (gh21704)$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8
```
 actually, hold on, i think I found a problem with my fix. I'll ping again once it's ready. Thanks. sorry this was a little bit more involved than I thought. I ended up adding more test cases as well and separated the variable vs fixed window code into two different functions so it's a bit easier to read. @jreback I think this is ready for you to take another look now.  looks good @changhiskhan if you can just run the asvs for min/max window ops to make sure nothing has significatnly changed.

@WillAyd if any comments, merge on good asv results. @WillAyd if you are ok, pls approve & merge