settings: Make DEFAULT_CONFIG public

This dictionary is accessed by plugins (like `summary`) which add new
settings, so it should be public (i.e. no prefixed underscore).

The changed name length would have led to a re-indenting of the
default contents anyway, so I shifted them all to four spaces.
settings: Rework the LESS_GENERATOR removal warning for easy extension

Setting migration is something that will happen for multiple settings,
and the more we can standardize the reporting procedure, the easier it
will be to add new warnings.
settings: Add a warning for folks using FILES_TO_COPY.
settings: Cleanup configure_settings() (standardization & types)

This pulls out some general patterns to make it easier to apply
existing processing to new settings.
tests.support: Use kwargs overrides in get_settings()

This avoids harcoding test-specific overrides, and makes it easy to
setup a settings dictionary based on DEFAULT_CONFIG for testing.
Because you can trust Pelican to use settings based on DEFAULT_CONFIG,
you are free to go about using:

  settings[my_key]

instead of:

  settings.get(my_key, some_fallback)

or:

  if my_key in settings:
      ...

if you know that `my_key` is in DEFAULT_CONFIG.
Replace settings.get(key) with settings[key] for default settings

If a setting exists in DEFAULT_CONFIG, assume it will be there
(instead of checking and/or providing a local default).  Existing code
is split between the two idioms, which can be confusing.