[meta] Standardize the approach for capturing and invoking callables across various subsystems

One of the problems we face in unifying this is that different places use 'ThisClass::thisMethod' to mean different things.

In FieldConfigInterface::setDefaultValueCallback(), a value of 'ThisClass::thisMethod' simply is a PHP callable, representing a static call to thisMethod() on the class ThisClass.

However, in the routing system, putting 'ThisClass::thisMethod' as the controller for a route will cause ControllerResolver to use the DI ClassResolver to instantiate ThisClass, and call thisMethod() on the instance:

  protected function createController($controller) {
    // Controller in the service:method notation.
    $count = substr_count($controller, ':');
    if ($count == 1) {
      list($class_or_service, $method) = explode(':', $controller, 2);
    }
    // Controller in the class::method notation.
    elseif (strpos($controller, '::') !== FALSE) {
      list($class_or_service, $method) = explode('::', $controller, 2);
    }
    else {
      throw new \LogicException(sprintf('Unable to parse the controller name "%s".', $controller));
    }

    $controller = $this->classResolver->getInstanceFromDefinition($class_or_service);

So given that, I think our new CallbackResolver will need two public methods, one for each behaviour: resolveCallbackWithStatic(), and resolveCallbackWithInstantiation()

1. Callbacks are not guaranteed to be serializable. Callbacks using static methods or instanced objects are not serializable at all.
2. All RenderElements have the DependencySerializationTrait for serialization into the caching and render systems.
3. This means there is a bug in the design of the trusted callback implementation for the Form and Render API.

#3259716: Replace usages of static::class . '::methodName' to first-class callable syntax static::method(...) issue gets into this, but currently TrustedCallback attributes / object->callback design breaks serialization for render arrays.

This can be seen in the core layout_builder module, which uses a TrustedCallback for pre-render. This breaks any render caching of the layout_builder element when cached in-memory.

Example: Install a Drupal Site from existing config with layout_builder enabled.
This isn't necessarily an emergency, as it's well know that --existing-config site installs are very easily broken by many contrib modules, but layout_builder is in Core.

Open Questions

1. Should RenderElementBase be extended with a RenderSerializationTrait that functions like the existing DependencySerializationTrait?
2. Instead, should DependencySerializationTrait be extended with _callbackObjects[] that will replace render array keys when serialized?
3. Is there another option, such as removing Serialization of RenderElements or adding a specific type of trusted callback that can be serialized for the Form and Render API?

I'd like to change the Issue summary to include this scope. Can someone recommend either: a separate issue to bubble to this Meta issue, or attaching to this issue that only covers #after_build and not all serializable element callbacks #3424106: Using a closure in #after_build may result in a "Serialization of 'Closure' is not allowed" exception ?