Nest the dynamic settings inclusion into a method

Alternative to https://github.com/ansible/django-ansible-base/pull/526

Well, it's not really an alternative, we could do both of them (a module for static settings & a module for function-ified settings), but this would also address our immediate problem.

Overall idea:

This puts most of our existing logic around dynamic settings into a method get_dab_settings. This keeps the canonical method of including settings, this just adds another layer internally. Benefits:

maintains an explicit interface, as opposed to an implicit interface which is what split_settings include necessarily does
allows projects like galaxy_ng to import the method and just get a simple python dictionary as a result. In doing so, it can just invent whatever value it deems necessary for INSTALLED_APPS and it's up to it for any modified settings, which should be more clear with how the RuntimeError is used here.
before, local variables were not really a thing, but now they are. For example, drf_authentication_class is just a variable that was never intended to be a setting. But the old dynamic include would have still put it in the settings. This makes things cleaner by maintaining inputs and outputs for the settings dynamic logic.

ansible / django-ansible-base

Nest the dynamic settings inclusion into a method #531

Quality Gate passed