Add more methods for conditional registrations to the core library

[dotnetjunkie]

The core library currently contains methods for conditionally registering open generic types and decorators using RegisterOpenGeneric and RegisterDecorator. This feature should be extended to non-generic or closed-generic registrations as well.

The extension of this feature can partly replace RegisterWithContext method that is currently given as example in the documentation. Just like with is possible with the RegisterWithContext, the feature in the core library should allow the user to make a decision on its direct parent. Ideally this information should also be included for conditional open generic registrations and decorators.

In contrast with the RegisterWithContext extension method however, the built-in feature should not allow users to supply a factory delegate, but only allow supplying either an implementation type or a Registration instance. Allowing a user to supply a factory delegate would blind the diagnostic system and would make the registration transient and thereby force all parents up the chain to be transient as well (to prevent lifestyle mismatches / captive dependencies).

While RegisterWithContext allows the object graph to be built-up using runtime decisions, the new core feature should only allow to make decisions based on information known during the building of the object graph, just as is currently the case with both open generics and decorators. The predicate is called a finite number of times and the information burned in the compiled code that builds the object graph. This is important, because runtime information should never influence the structure of the object graph. The shape of the object graph should be fixed, and runtime information should instead be queried at runtime to change the application's call graph; not the object graph.

Although tempting, this new feature should not allow a registration to query information beyond its direct parent. Analyzing the parent's parent might seem useful, but will give incorrect results if direct parent is anything but transient (again causing the whole object graph to become transient).

While the RegisterWithContext only supports dependencies that are injected as constructor argument, the core feature should also support dependencies that are injected through property injection, since the core library supports property injection.