Add type mapping support for container ID override

Start by reading the existing ParameterResolver interface and Resolver implementation to understand how parameters are currently resolved through the container. Add the new ParameterResolverWithTypeMap contract and verify that Resolver supports both interfaces while accepting type-to-container-ID mappings. Review the existing test suite for resolver behavior and cover aliases, multiple implementations, and backward compatibility.

The Resolver resolves parameters by looking up types directly in the container using ->get(). This doesn't work when:

1. Multiple implementations of an interface exist in the container, and you need to specify which one
2. Services are registered with string aliases (e.g., 'my.favorite.animal') instead of class names

Currently there's no way to tell the Resolver "when this callable needs an Animal, look up 'my.favorite.goat' from the container."

Introduce a new interface ParameterResolverWithTypeMap extending ParameterResolver with an additional method:

interface ParameterResolverWithTypeMap extends ParameterResolver
{
    public function resolveWithTypeMap(
        ReflectionFunctionAbstract ,
        array ,
        array<string, string> 
    ): array;
}

Usage:

$args = $resolver->resolveWithTypeMap(
    $reflection,
    $arguments,
    [Animal::class => 'my.favorite.goat']
);

The Resolver class would implement both interfaces, maintaining backward compatibility.

Additional context

This approach preserves backward compatibility - existing code using ParameterResolver continues to work unchanged. Clients can build the type map externally based on their needs and pass it at call time.