Add container compilation

[frederikbosch]

A goal of compiling the container, is that reflection does not need to be used anymore after compilation. A compiled container knows all the object meta information to resolve/construct objects. It has only one task left: instantiating new instances.

Therefore, before creating the container compiler, we need to make sure reflection is not a requirement after unification of objects, which is a process inside Resolver. This PR will change two things.

1. The Blueprint class constructs new objects, but used reflection to do so. From now on, it will use new $className.
2. The expandParams call in Resolver will be moved to the Blueprint because it is part of the object construction. The method also used reflection to determine whether a parameter is variadic. From now on, the Blueprint knows all parameters of an object with its parameter settings, including if it is variadic or not. This removes another need for reflection during object construction.

And finally, this PR adds the feature of container compilation. All objects that are added through $di->params, $di->setters and $di->mutations, plus extra objects that can be passed, are compiled into blueprints.

After this PR is merged, a container might be constructed as follows.

$serializedContainerFile = '/var/compiled.ser';

if (file_exists($serializedContainerFile)) {
  $di = \unserialize(file_get_contents($serializedContainerFile));
} else {
  $config_classes = [
      new \Aura\Di\Fake\FakeLibraryConfig,
      new \Aura\Di\Fake\FakeProjectConfig,
      new \Aura\Di\Fake\FakeCompilationTestConfig(),
  ];
  
  $extra_classes = [
      FakeConstructAttributeClass::class
  ];

  $builder = new ContainerBuilder();
  $di = $builder->newCompiledInstance($config_classes, $extra_classes);

  $serialized = \serialize($di);
  file_put_contents($serializedContainerFile, $serialized); // atomic for concurrency
}

$di = $this->builder->configureCompiledInstance($di, $config_classes);

[frederikbosch]

This PR leaves one final question, at least for me, how to scan classes for attributes? Should we add such an attribute scanner? Which one is used by other projects? Or does each framework has its own scanner?

@koriym How are you solving that in your project?
@harikt Do you have any experience with that?

[koriym]

@frederikbosch BEAR.Sunday needed to support a mix of doctrine/annotations and PHP8 attributes, so I created Koriym.Attribute. (Mentioned in PHP Annotated - 2022 Spring )

The attribute read part is very simple.

https://github.com/koriym/Koriym.Attributes/blob/1.x/src/AttributeReader.php#L87-L93

[harikt]

I have no idea on this. May be want to look into other compiler DI . Also please do look into the recent discussions on the php-fig regarding compiled container.

[frederikbosch]

I removed the comments I made earlier on. The solutions have been simplified significantly.

When the ContainerConfigClassScanner is added as config class to ContainerBuilder, it will scan for classes and attributes. Attributes can modify the container. This means that if it finds a #[Route] attribute, it can be added to a list of routes in the container. It is possible to do so for both self-created and external attributes. This makes Aura/Di ready to work with attributes from any project or library.

Furthermore, the documentation contains:

• an example of a fully-featured container in the getting started section.
• explanations how to create attributes that modify the container.
• explanations how to compile and serialize the container.
• explanations how to scan for classes and annotations.
• explanations how to compile other classes when compiling the container.

[frederikbosch]

I renamed ContainerConfigClassScanner to ClassScanner. I believe there is no real value in prefixing (or post-fixing) the class name. Other than that, I think it's good to go for merging and an alpha release of 5.x.