setSettings() on field definitions can unintentionally clear default values

This was originally found in #2209981: ConfigurableEntityReferenceItem should not mess with the field schema and is similar in nature to #2235125: Use DataDefinition::addConstraint() instead of ::setConstraints().
It also causes #2472443: BFD::createFromFieldStorageDefinition() creates a broken field definition (no field-level settings)

Problem/Motivation

DataDefinition::setSettings() is used all over core to set multiple settings at once. However, it currently removes default settings if those are not explicitly specified.

Proposed resolution

As per #36 :

TypedData doesn't have a notion of "default settings", it can be argued that TypedData\DataDefinition::setSettings($settings) overwriting existing settings is fair - it's a setter after all.

But fields do have this notion of default (field-level / storage-level) settings, and a FieldDefinition that doesn't have an entry for an "official" setting is invalid / broken. There is no unsetting a field setting, the moment a setting is defined, consuming code assumes it is set in any runtime field definition.

So the patch leaves the generic TypedData's DataDefinition::setSettings() untouched, and instead modifies the method in field / field storage definitions (BaseFieldDefinition / FieldConfigBase / FieldStorageConfig) so that they merge rather than replace.

The current patch also replaces a bunch of usages of setSettings() with repeated calls to setSetting() as (arguably) this is more readable and was necessary for previous iterations of this patch. This can be removed in case people feel strongly.

API changes

The setSettings($settings) method in BaseFieldDefinition / FieldConfigBase / FieldStorageConfig no longer overwrites the current settings with the new ones, but rather merges the new ones into the old ones, to ensure no setting goes missing.

Beta phase evaluation