Collapse the FEATURES dictionary into boolean settings

[kdmccormick]

Both LMS and CMS settings have a big FEATURES dictionary. The values are all booleans.

There are also many boolean settings outside of the FEATURES dictionary.

It adds unnecessary complexity to have so many booleans stuffed into one FEATURES dictionary. It makes these values harder to override individually, both in unit tests and in the settings files themselves. There is no particular reason why these are in a dictionary.

Goals:

• Flatten the keys of FEATURES into the settings namespace
• Update all references in edx-platform
• Create a proxy FEATURES dictionary which allows external code to seamlessly read and write these settings as is they were still part of the FEATURES dictionary.

[kdmccormick]

@wgu-taylor-payne

[robrap]

@kdmccormick: It sounds like the last bullet, the proxy idea, is part of an expand phase. Are you hoping to have a contract as well? I don't think this necessarily needs a DEPR, but you may want to consider just if you want to use the inform process.

One question about DEPR process vs refactors, are whether we can get tickets through with auto-acceptance for expansion (like in cases where we were going to skip DEPR anyway), and then just negotiate possible contract timeline.

This is all food for thought. Maybe a DEPR comes later just for the proxy if you ever want to initiate removal?