Add a user interface so that users can administer features

Do we need a new third party setting for a description? Right now, when configuring the a specific feature, I can not distinguish the given alternatives. The feature name is shown, but this is the same for all configs.

@alexpott thats even better then adding a new description option, it would also be beneficial outside the selector UI to have those descriptions in good shape.

I have tested UI a bit. It looks nice and it makes a general idea more useful and transparent to the user - I like it.

There are few things that I have encountered. Maybe it's not directly related to UI, but it's easier to notice it now.

1. When we have blocks and views in one feature. There are two tables and columns are not nicely aligned, that looks a bit ugly. Is it possible to join results in one table? with headers for every of config type (if I can call it like that)
2. Some kind of sorting in the table of available configurations for the feature would be nice - I would suggest priority order
3. One use case: I have two blocks and they are both activated in blocks UI. When I go to the configuration selector feature management page, they are both enabled and I don't have the option to disable any of them, just to edit them. I'm not sure, should we provide disable option or promote option (that's our select option) since configuration state (according to configuration selector behavior) is not in the correct state. I'm not sure if we can or should address this case?
4. This error occurred for me. I have tested it on Search API PR from Thunder: https://github.com/BurdaMagazinOrg/thunder-distribution/pull/434 - I enabled Search API and Media View for it was enabled. So there are 2 views for one feature. Then I deleted active view and my site crashed because a view is not available. Should config selector jump in and set an available view for that feature as active or we are not planning to handle explicit deletion of config?
5. When I delete all configurations related to one feature, feature still exists in list, but manage page is empty. Question is, should we hide features without any available configuration or not? Or maybe just disable manage configuration button for that feature, what would be also nice solution?

I have found just a few code nitpicks:

1. +++ b/src/Controller/Switcher.php
   @@ -0,0 +1,80 @@
   +        $entity->setStatus(FALSE);
   

   It would be nice to add logging for all configs where status is changed.

2. +++ b/src/Entity/Feature.php
   @@ -0,0 +1,110 @@
   +    foreach (\Drupal::entityTypeManager()->getDefinitions() as $entity_type) {
   ...
   +    $entity_storage = \Drupal::entityTypeManager()->getStorage($entity_type_id);
   

   Can we use $this->entityTypeManager() here?

3. +++ b/tests/modules/config_selector_ui_test/config_selector_ui_test.install
   @@ -0,0 +1,57 @@
   +  $node_optional_dir = drupal_get_path('module', 'node') . '/config/optional';
   +  $node_config_storage = new FileStorage($node_optional_dir);
   +  $view_data = $node_config_storage->read('views.view.content');
   

   Nice one!

4. +++ b/tests/src/Functional/ConfigSelectorUiTest.php
   @@ -0,0 +1,105 @@
   +    $view_storage = \Drupal::entityTypeManager()->getStorage('view');
   

   It would be nice to move \Drupal::entityTypeManager() into variable.

5. +++ b/tests/src/Functional/ConfigSelectorUiTest.php
   @@ -0,0 +1,105 @@
   +    $this->assertEquals('Test configuration', $this->xpath('//table[1]/thead/tr[1]/th[1]')[0]->getText());
   +    $this->assertEquals('View', $this->xpath('//table[2]/thead/tr[1]/th[1]')[0]->getText());
   

   Since we are using [@id="edit-table"] everywhere it would be better to use same selector here, just to reduce confusion. I think it's: "edit-table" and "edit-table--2".

I have tested changes and checked also code. It looks good to me and from my point of view, we can commit it.

P.S. There are few drupal coder styles that could be adjusted, but that can be done before commit.

Crediting @mtodor for reviewing

Fixed