Fix issues with multiple factories that implement the same interface

[gjoseph]

Assuming a bug in either auto-common or dagger-compiler. Since the latter depends on 1.0-SNAPSHOT of the former, it seems that having 0.3 in auto-factory messed things up. Set it back to snapshot here until a new release of auto-common is available and/or it is shaded into dagger-compiler.

Somehow I'd have expected this kind of problem to break the build, but this isn't the first time I notice an annotation processor that just silently does nothing.

[googlebot]

Thanks for your pull request.

It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA) at https://cla.developers.google.com/.

If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check the information on your CLA or see this help article on setting the email on your git commits.

Once you've done that, please reply here to let us know. If you signed the CLA as a corporation, please let us know the company's name.

[gjoseph]

Ok, so I actually wanted to do 2 different PRs, one for the build (since it meant I couldn't generate an auto-factory.jar) and one for #82 but for some reason forgot to branch out. Let me know if you'd really rather have 2 individual ones ?
(re: the fix-build commit, I wasn't actually able to really identify what was wrong, but it seemed to be somewhere in the depths of Dagger's ComponentProcessor)

[googlebot]

CLAs look good, thanks!

[gjoseph]

.. and the revert of 55bda7e shows the same results on Travis - target/classes is empty !

[gjoseph]

Rebased PR on current master, which now depends on auto-common 0.4 (which should address the bug I had with the dependency to 0.3)

[tcz]

What is this PR waiting for?

[netdpb]

I believe this PR is obsolete at this point. If you still experience this issue, please file a new bug with a repro example.

Thanks!