Windows path fix: should do like Django, not like Windows

[SonOfLilit]

In March I was in a hurry and I locally fixed a path issue where Django always worked with '/' but db_file_storage worked with os.sep (I fixed it locally because it was above the @sp-niemand fork that fixed Django 1.9, so contributing the fix was not easy anyway.)

This is my fix:

https://github.com/SonOfLilit/db_file_storage/commits/master

I recently noticed that the issue was fixed upstream (as well as the Django 1.9 support that was blocking me from using the official release):

https://github.com/victor-o-silva/db_file_storage/pull/28

However, when I tested the new version, I found that the official fix converted Django's forward slashes to backslashes on Windows, instead of using forward slashes internally on Windows too like Django does, and like a db-based storage plugin should, so I'm stuck on my unofficial version.

The abstract issue is that there is no relation between a storage plugin and the operating system, so why should the storage plugin introduce a portability issue between operating systems, or depend on the operating system for it's API/ABI in any way?

An example concrete issue is that I can't clone the production DB and work on it from a Windows machine. Few people ever host production Django systems on a Windows server [citation needed], so dev environments for systems that are hosted on Unix in production is the major use case for using Django on Windows, and therefore this matters.

I propose moving to my fix and creating a migration that converts all existing paths in the DB to forward slashes (perhaps only do it if there are slashes in the config part of the stored paths... Windows does not allow backslashes in a filename, does Unix?).

I can write the code if you like the idea and are willing to do Code Review.

Aur