io.fits tests fail on appveyor/windows as memmap behaviour has changed

I’m not completely sure when this became a problem, and suspect it is related to a numpy update, but recent appveyor builds (e.g., https://ci.appveyor.com/project/Astropy/astropy/build/1.0.6535/job/y82p08ealenwojtl) at a spot for which there is a specific comment that it is a horrible hack:

            if sys.platform.startswith('win'):
                # On Windows, all the original data mmaps were closed above.
                # However, it's possible that the user still has references to
                # the old data which would no longer work (possibly even cause
                # a segfault if they try to access it).  This replaces the
                # buffers used by the original arrays with the buffers of mmap
                # arrays created from the new file.  This seems to work, but
                # it's a flaming hack and carries no guarantees that it won't
                # lead to odd behavior in practice.  Better to just not keep
                # references to data from files that had to be resized upon
                # flushing (on Windows--again, this is no problem on Linux).
                for idx, mmap, arr in mmaps:
                    if mmap is not None:
>                       arr.data = self[idx].data.data
E                       DeprecationWarning: Assigning the 'data' attribute is an inherently unsafe operation and will be removed in the future.
astropy\io\fits\hdu\hdulist.py:1342: DeprecationWarning
 2 failed, 11580 passed, 200 skipped, 79 xfailed, 1 xpassed in 417.46 seconds =

[mhvk]

#9228 failed, i.e., we still need the work-around for windows: any memory maps need to be closed before resizing the file.

[mattip]

I think a user having a reference to hdu is not as much of a problem, as then getting data might well do the right thing.

That was my intention