Settings class bulletproofing

Previous implementation of Settings class had some flaws.

1. `settings.Settings.__getattr__` was called for all attributes that were not found, even for `DEFAULT_<SETTING_NAME>`. Retrieving `<app>_settings.<SETTING_NAME>`, if neither `django.conf.settings.<APP>_<SETTING_NAME>` nor `<app>_settings.DEFAULT_<SETTING_NAME>` existed would have led to infinite recursion of retrieving `DEFAULT_DEFAULT_DEFAULT_...<SETTING_NAME>`. 

   Solved by raising `AttributeError` for nonexistent attribute names starting with prefix denoting default setting.

2. In statement `getattr(obj, 'attr_name', some_function())` function call `some_function()` is always executed, before retrieving `obj.attr_name`. So in `settings.Settings.__getattr__` default setting was always retrieved (though not returned), even if corresponding setting existed in `django.conf.settings`. If e.g. `<SETTING_NAME>` is required and so `DEFAULT_<SETTING_NAME>` is a property that raises `ImproperlyConfigured` exception this exception would have been raised even if `django.conf.settings.<APP>_<SETTING_NAME>` existed.

  Fixed by using explicit `try ... except ...`.

3. Using, in an application, setting with name that starts with `DEFAULT_` could have led to unexpected interference with mechanism of retrieving default settings.

   Fixed by prefixing default setting names with underscore, so that they are much less likely to cause naming collision.