Filter out non-modules when trying to instantiate a module

[lihaoyi]

Fixes https://github.com/com-lihaoyi/mill/issues/6303

[lefou]

Is filtering / ignoring the right solution? Shouldn't we either error our or require the user to not mix-in MainModule (which is currently not configurable)?

If we just filter out, what is the correct behavior for mill init in the example given in #6303?

[lihaoyi]

I'm not sure TBH, but we already have an init module in the Mill codebase that would conflict with the init task that Mill comes bundled with, so presumably it won't be uncommon to have such collisions and if we could make it work without error that would be nice

[lefou]

I'm not sure TBH, but we already have an init module in the Mill codebase that would conflict with the init task that Mill comes bundled with, so presumably it won't be uncommon to have such collisions and if we could make it work without error that would be nice

I think the init module we have is libs.init and not a top-level module, so it won't collide with MainModule.init.

I think there is no room to gracefully handle collisions, if we speak about CLI and API modelling the same name space. E.g. a init module implementing DefaultTaskModule already collides on the CLI. But using some build.init.compile() task via API has to collide when compiling it, if build.init is aleady a task inherited from MainModule.