getOverrideOptionsFromPropertyName() doesn't return the correct array

Problem/Motivation

There are 2 issues noticed here. The patch in comment #2 should solve issue #1. Issue #2 is related (thus I logged here) but I don't have time to do it, yet. It'll be good if anyone wants to pick up and provide the patch for the second issue.

Issue #1

Simple typo in ConfigManagerService::getOverrideOptionsFromPropertyName() in src/ConfigManagerService.php:43, resulting in both the key and value returned are the class.

So when given the following overriding options config:

layout--background--none|None
layout--background--red|Red
layout--background--black|Black

It results in the wrong returned options array:

'layout--background--none' => "layout--background--none"
'layout--background--red' => "layout--background--red"
'layout--background--black' => "layout--background--black"

It should have been:

'layout--background--none' => "None"
'layout--background--red' => "Red"
'layout--background--black' => "Black"

Issue #2

When the overriding options are the following: (notice the missing label for Black)

layout--background--none|None
layout--background--red|Red
layout--background--black

Black is completely missing in the returned array:

'layout--background--none' => "layout--background--none"
'layout--background--red' => "layout--background--red"

The default core behaviour (see List (text) field type) is to append the label to be the same as the key IN the config itself at the point of config form submission—rather than having a logic test filtering out option with missing labels. So after saving the config, the value stored in database should be automatically changed to:

layout--background--none|None
layout--background--red|Red
layout--background--black|layout--background--black

In this case, there is no need to change the logic in getOverrideOptionsFromPropertyName() for issue #2.

Proposed resolution

Issue #1: Simply change the assigned value to $data[1] (which is the label) instead of $data[0] (the class).
Issue #2: Fix the behaviour of SettingsForm:submitForm() to match that of core behaviour.

Remaining tasks

1. Issue #1: Commit the patch below.
2. Issue #2: Look into field API behaviour and standardise the behaviour when the label not present in the options config. Maybe there is trait somewhere we can just use.

User interface changes

Issue #2: potential change of UI text and behaviour to match those of List (text) field.

API changes

None.

Data model changes

None.

Release notes snippet

- Fix getOverrideOptionsFromPropertyName() to return the correct class (key) and label (value) for options.
- Automatically append label (value) in options config override when only class (key) is provided.