I don't think anyone can explain it better than Martin Fowler does, further down the article you linked to.
For this new breed of containers the inversion is about how they lookup a plugin implementation. In my naive example the lister looked up the finder implementation by directly instantiating it. This stops the finder from being a plugin. The approach that these containers use is to ensure that any user of a plugin follows some convention that allows a separate assembler module to inject the implementation into the lister.
As he explains in the paragraphs above that, this is not quite the same as the reason the term "Inversion of Control" originated.
When these containers talk about how they are so useful because they implement "Inversion of Control" I end up very puzzled. Inversion of control is a common characteristic of frameworks, so saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels.
The question, is what aspect of control are they inverting? When I first ran into inversion of control, it was in the main control of a user interface. Early user interfaces were controlled by the application program. You would have a sequence of commands like "Enter name", "enter address"; your program would drive the prompts and pick up a response to each one. With graphical (or even screen based) UIs the UI framework would contain this main loop and your program instead provided event handlers for the various fields on the screen. The main control of the program was inverted, moved away from you to the framework.
Which is why he goes on to coin the term "Dependency Injection" to cover this specific implementation of Inversion of Control.
As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.
To clarify a little: Inversion of Control means anything which inverts the control structure of a program from the classic procedural design.
In days of yore, a key example of this was letting a framework handle communication between a UI and your code, rather than leaving your code to generate the UI directly.
In more recent times (when such frameworks pretty much dominated, so the question was no longer relevant), an example was inverting control over the instantiation of objects.
Fowler, and others, decided that the term Inversion of Control covered too many techniques and we needed a new term for the specific example of instantiation of objects (Dependency Injection) but, by the time that agreement had been made, the phrase "IoC Container" had taken off.
This muddies the water a lot, because an IoC container is a specific kind of Dependency Injection, but Dependency Injection is a specific kind of Inversion of Control. This is why you're getting such confused answers, no matter where you look.