* 0024_remove_duplicate_attributes.py handle multiple attribute values with same attribute code

* Use _get_value instead of copying the method

* Implemented predefined product options

* css

* added missing migration in the test app

* Added tests

* added test

* added test

* Added more testz

* Added validation

* Renamed add_optional_choice to add_empty_choice

* added release notes

* Added help_text help text.

yup

* Use a JSONField for the option value

* removed pylint

* fix display of multi and checkbox in basket and order (#13)

* fix display of multi and checkbox in basket and order

Co-authored-by: willeke huizing <38961397+willekeh@users.noreply.github.com>

Co-authored-by: Basil Dubyk <samitnuk.work@gmail.com>
Co-authored-by: Alexander Gaevsky <sasha@sasha0.ru>
Co-authored-by: Joseph Wayodi <jwayodi@gmail.com>

So that migrations are not required for changes to the
"OSCAR_IMAGE_FOLDER" setting, for projects that have not forked the
"catalogue" app.

When looking up a URL for a forked app, the previous mechanism fetched the top level AppConfig which allows every user.
The new mechanism creates a dict of dashboard URLs/configs and does a lookup to find a DashboardConfig.

This will also raise NoReverseMatch if the URL does not exist or is not a dashboard URL.

fix https://github.com/django-oscar/django-oscar/issues/3080

- Move Oscar app configs into Django app config classes
- Rename Oscar/Django apps' app config module
- Remove "oscar.get_core_apps()" and its app overriding
- Remove "oscar.OSCAR_CORE_APPS"
- Port app forking code to work with Django app registry
- Port class loading code to use app configs to get app properties

Previously, validation did not pass when current locale is "en-gb" and URL is "/de/catalogue/" and visa versa due to default Django URL resolvers behaviour  - they do not take into account all locales, only current.

Now after ConditionalOffer deleted will be deleted related Benefits and Conditions models (through post_delete signal) if they are no longer used by other offers (with exception of custom benefits/conditions). Plus some small changes related to PEP8 and typos.

The copying of the email address within the datamigration isn't really
optimal when a site has a large number of users and send emails.

Most real-world instances will use postgresql instead of sqlite so it's
better to use postgres for the tests. This also allows us to easily add
tests for concurrency issues which is not supported by sqlite

This fixes a DeprecationWarning

This also updates the pytest dependencies

 - Set Meta.app_label on models created in the tests
 - Use logging.NullHandler instead of django.utils.log.NullHandler
 - Use oscar.core.loading.get_model() instead of django's get_model
 - Remove template tags '{% load url from future %}'

This has been around since forever, and removing it is overdue. I took
the opportunity to slightly improve the urls.py files.

The changes should be obvious and non-controversial. Under Django 1.7+,
the AppConfig is used to register signal receivers instead of just
registering then when models are registered.

Adds new functional tests for ShippingAddressView, PaymentDetailsView
and ThankYouView.
It's the second part of #1645.

Notes

* Adds a custom template to be able to test some functionalities of
  PaymentDetailsView
* Adds an helper to the CheckoutMixin

The config was picking the wrong directory so the custom test templates
were not used during tests.

Notes

- Fix missing i18n load tags
- Remove mixed tab/space indentation
- Add two settings tests

When adding a migration on master, I discovered that the new-style
migrations were strongly out of sync; Django wanted to create new
migrations for almost every app. That was surprising given that no model
changes were made since building that set of migrations.

The issue is that they were built with Django 1.7 RC2, and we've since
switchted to RC3. If I'd have to guess, I'd say the following issue is
responsible for it:
2da20379c0

As beta 1 is only a day old and it doesn't cause major headaches, it was
decided that it's easiest to release a new set of migrations. And pray
to the gods of Python that we won't have a similar situation again
before the Django migrations framework stabilises.