Document limitations of get_classes

I investigated for a few minutes if it's possible to get
get_class('shipping', 'Scales') working. oscar_module loads correctly,
but any overriding local_module was missing classes defined therein.

Just documenting this limitation explicitly instead of tripping at the
ValueError when trying to split.
Rename and move Scales class, and make it overridable

Making it overridable allows altering the weighing method of the basket,
which I wanted to do in a project. As get_classes doesn't support
importing from top-level products, it had to be moved to a scales
module.

Other class names tend to use singular, so as the imports had to be
changed anyway, Scales was renamed to Scale.
Tweaks for model-based shipping methods

* Made upper_limit a DecimalField, like the other weight fields
* Increased default precision for weights to be to the gram level. Will
  be useful for deployments shipping smaller items such as stickers,
  where 10 grams precision is too low.
* Changed strings to official 'kg' abbreviation.
Drop unused Javascript from demo site

Alex Moon ran into an issue which led to us grepping through the code
base and discovering some Javascript libs aren't used by the demo site.
Remove crate.io and oscar-testsupport from README

Crate.io is no more, and testsupport has been deprecated for a long time
now.
Replace CsvUnicodeWriter with Python 3 compatible UnicodeCSVWriter

This required extending the UnicodeCSVWriter to be able to deal with
file-like objects as well. This is used to create downloadable CSV files
in memory.
Fix or ignore DeprecationWarnings in test suite

* WebTest throws a DeprecationWarning under Python 3 that we can't do
  anything about. Added to the excludes.
* assertEquals has been deprecated, renamed to assertEqual.
Python 3 fixes for NullCharField

The metaclass definition did not work with Python 3, to_python wasn't
called. Documented in:
https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#django.db.models.django.db.models.SubfieldBase

Also clarified logic of the to_python logic.
Backport import_string from Django

This allows importing a class or attribute by the reasonably common
string notation, which is useful for e.g. settings. When using settings,
we should prefer absolute imports over using get_class, because that
limits us to modules in INSTALLED_APPS.
Update trove classifiers to be explicit about Python 2 and 3 support
Merge branch 'master' of https://github.com/tangentlabs/django-oscar into feature/demo-multipayment-with-faceted-catalogue