I can suggest registering only ConcretePlugin, then use it to resolve eveything that might depend on it.

For example:

sc.AddSingleton<ConcretePlugin>();
// Resolve IPlugin using already registered instance.
sc.AddSingleton<IPlugin>(sp => sp.GetRequiredService<ConcretePlugin>());

Update

In order to register type as itself and as interface implementation for each implemented interface (and return one single object all the time), you can use such method:

public static class ServiceExtensions
{
    public static IServiceCollection AddTypeAsItselfAndInterfaces<T>(this IServiceCollection services)
        where T : class
    {
        var implementedInterfaces = typeof(T).GetInterfaces();
        services.AddSingleton<T>();
        foreach (var implementedInterface in implementedInterfaces)
        {
            services.AddSingleton(implementedInterface, sp => sp.GetRequiredService(typeof(T)));
        }
        return services;
    }
}

@MichałTurczyn already gave the answer for MS.DI, so I won’t repeat that. Here’s how to do it with Simple Injector:

var container = new Container();

var concrete = new ConcretePlugin(/*some arguments here*/);
container.Collection.AppendInstance<IPlugin>(concrete);
container.RegisterInstance(concrete);
container.Register<TestConcrete>(Lifestyle.Singleton);
container.Register<TestList>(Lifestyle.Singleton);

container.GetInstance<TestList>();

Autofac supports what I think you’re looking to do, but before I explain the answer, let me explain why I think you might be asking the wrong question.

Autofac, and the majority (maybe all?) of the .NET DI frameworks are built on the notion of separating the concepts of…

• Component: This is the class that you’re registering, the body of code that has the executable bits.
• Service: This is the interface, or the way that the component exposes its executable bits.

So when you register things in pretty much any DI framework in .NET, you’ll see a rough pattern of “register component X and expose it as service A.”

In the “pure DI” example, you – the human – are making a choice to say “I want to expose ConcretePlugin as two different services: as itself and as IPlugin. The type system allows that to happen, but the programmatic consideration of what services you expose and how was made (intentionally or unintentionally) by you.

The reason it seems “dead simple” is because you’re mentally skipping over the creation of the component-to-service mapping because that’s inherent in the type system.

So why don’t DI frameworks just “skip over that” as well, and let every component be exposed as every service? That’s probably a better question, and I think it’s a combination of:

• Performance: If I have a strict map of component-to-service, I can do very fast lookups to see which components I have that can be injected into the dependencies of other components. If I need consider that component to be able to expose every service it could possibly expose (interfaces, base classes, etc.) then I’d need to build a cache of every possible thing it could fulfill (probably pretty sizable in a large system) and look that up for every parameter and property I inject, every time.
• Brownfield projects: I may not actually own the code I’m working in, or may (due to various restrictions) not be allowed to change it. But I don’t want component X to be injected as a service A ever. Yeah, it may implement that interface, and I may need to inject it, but I don’t want it exposed using that interface for whatever reason.
• Predictability: Generally the order of registration is the order in which the services will be picked to fill in dependencies. If the underlying code changes, that may have unpredictable effects on which component gets chosen to satisfy a dependency.

Let’s walk that latter one through an example. Say you have this:

// This is PSEUDOCODE. It's in Autofac-ish style, but
// we're pretending that registering a type will also
// expose it as all of its interfaces by default. That's
// not how Autofac works.
var builder = new ContainerBuilder();

// A class `First` that implements the `IFirst` interface.
builder.RegisterType<First>();

// A class `Second` that implements the `ISecond` interface.
builder.RegisterType<Second>();

// A class that takes, as dependencies, `IFirst` and `ISecond`.
builder.RegisterType<ConsumesIFirstAndISecond>();

Now let’s say this is a pretty large project. At some point, someone makes the choice to add the IFirst interface to the class Second. You know what happens now? The ConsumesIFirstAndISecond will get two copies of the class Second.

That’s not an impossible-to-debug issue, but if you’re working in a project with a team of folks of varying skill levels, it can be a non-zero-time thing to figure out. (At which point you’ll possibly file an issue or raise a StackOverflow question asking why DI frameworks don’t allow you to expressly specify the service during registration because that would have saved you a ton of time and this seems like a dead simple thing to allow).

Anyway, you see where I’m going there. DI isn’t a type system. I think the analogy of “here’s what no-DI vs. DI can do in a two line example” is maybe oversimplifying the issue. I mean, if what you want is the no-DI behavior, then… just use no DI, right?

But all that said, I did say I’d show you how Autofac can do this.

There are two things that Autofac has that you should be aware of:

• AsSelf() – this exposes a class as itself and is the default unless other services are explicitly specified.
• AsImplementedInterfaces() – this is basically the helper method that other answers have mentioned you might have to write. It goes through and registers a given thing as all of its interfaces.
• ContravariantRegistrationSource – this basically “opts you in” to allowing you to resolve types in a contravariant context. It’s not helpful in this specific example, but since you’re interested in a similar area here, I figured I’d include it.

For what you want, AsSelf() and AsImplementedInterfaces() are the key.

var builder = new ContainerBuilder();
builder
  .RegisterInstance(new ConcretePlugin(/*some arguments here*/))
  .AsSelf()
  .AsImplementedInterfaces();
builder.RegisterType<TestConcrete>().SingleInstance();
builder.RegisterType<TestList>().SingleInstance();
var container = builder.Build();

// These will work.
container.Resolve<TestConcrete>();
container.Resolve<TestList>();

Anyway, I hope that all helps clarify a little. Whether it’s satisfying or not is another question, but maybe at least it explains it a bit.