Only load editable settings from the database.

If a Mezzanine-registered setting is defined in the database and also in settings.py, it's considered not editable, but it's loaded from the database anyway when an editable setting is first accessed.

I think this is wrong, because:

* Subsequent accesses of a non-editable setting can return different values, if an editable setting is accessed for the first time in between them.
* The setting is hidden from the admin interface, implying that the settings.py value will be used, but the database value is used. The actual returned value isn't visible anywhere except by interrogating the database directly.

This patch makes the settings.py value take priority over the database value if both are defined, and emits a warning in this case. I've also put the whole settings loading procedure into its own method.