`use entrait::*` often clashes with `use unimock`, since there is a `unimock` module in entrait

[audunhalland]

should reconsider the idea of different "entrait scopes" for mocks.

Alternatives:

1. always require attribute options for generating mocks
2. control mock generation via cargo features

the second option could be interesting, because then libraries could more easily support entrait annotations without any cost: i.e. no features would generate no extra code; everything is opt-in. The applications selects the mocking framework it wants via a feature selection. An important thing to consider in that case is that features must have an additive design, features will be the same in every usage of entrait, regardless of which crate invoked it.

An important point to remember about entrait is that (I think) some entrait patterns will be uniform within a single crate, some patterns will be uniform within a whole binary:

feature	"width"
mock library	application/binary wide
mock cfg(test)	crate wide

[audunhalland]

Fixed in 0.4. This version adds new cargo features, and adds a new concept of exporting mocks.