So this should fail not because includes=someinterface, but because includes=non-module.  

I don't think this PR really addresses the question of whether interfaces can be modules.  For instance.

```
@Module(entryPoint=Something.class)
interface MyModule {
  @Provides Something providesSomething(SomethingImpl impl);
}
```

Should that be valid if someone actually creates an anonymous subclass that makes provideSomething callable?  Should it be valid because we can easily infer with reflection or code-gen that this is so?   Or should interfaces-as-modules represent some sort of "contract" for a module and any module that conforms to that contract should be swappable for this one at run-time, with checks agianst it, etc.  Jesse and I talked about something along these lines, though it needs a LOT more fleshing out.

The point is that I think this should fail only because it's not a valid module, not because it is an interface. 

The fact that interfaces aren't valid modules is the current situation, but the approach sort of sweepingly declares that they cannot be, and I can see a few different reasonable uses for interfaces in the module configuration system.