Overhaul settings.

[orlnub123]

This overhaul fixes a couple of bugs and makes the code simpler. The bugs it
fixes are:

• Being able to set non-upper attributes directly on the settings object e.g.:

  from django.conf import settings
  
  settings.foo = 'bar'  # Doesn't error
  print(settings.foo)
  

• Being able to delete the same setting multiple times on user configured settings e.g.:

  from django.conf import settings
  
  settings.configure()
  # Doesn't error
  del settings.TEST
  del settings.TEST
  del settings.TEST
  

• Settings.is_overridden ignoring set and deleted settings directly on the settings object e.g.:

  from django.conf import settings
  
  assert settings.is_overridden('TEST')
  del settings.TEST
  print(settings.is_overridden('TEST'))  # True; should be False
  
  assert not settings.is_overridden('TEST2')
  settings.TEST2 = 2
  print(settings.is_overridden('TEST2'))  # False; should be True
  

The biggest change is that now user configured settings are evaluated immediately instead of on-demand via a __getattr__. This was done to fix the second bug in the simplest way. If all settings live in the __dict__, you don't have to fake attribute deletion.

[Mariusz Felisiak]

Django doesn't support ​altering settings at runtime, so described modifications are not support.

[orlnub123]

Some packages alter settings after configuration but before runtime, such as django-appconf. I'd even argue that this reduces settings "altered" at runtime, as all user configured settings are evaluated immediately, so you can't have properties that would change their output after the fact.

In reality, these fixes probably help more with the tests than user code, as they're the reason UserSettingsHolder even has a __setattr__ and __delattr__. This can be seen in my PR as I've had to fix a test that relied on broken behavior.