SI-7157 fixes the arg <-> params conformance check in macros

@paulp was right. We should abstract this away, otherwise it's too easy
to make a mistake.
sbt compatibility for introduceMember
SI-7047 fixes silent for c.inferImplicitXXX

silent = true now throws a TypecheckException even if we don't know why
an implicit search has failed (i.e. if context.hasErrors is false).
SI-7166 catches DivergentImplicit in c.inferImplicitXXX

Despite inferImplicit usually being nice and buffering errors, apparently
it can also throw DivergentImplicit exception. This patch catches it and
only reports it if silent is set to false.
SI-7167 implicit macros decide what is divergence

Imagine a macro writer which wants to synthesize a complex implicit
Complex[T] by making recursive calls to Complex[U] for its parts.

E.g. if we have `class Foo(val bar: Bar)` and `class Bar(val x: Int)`,
then it's quite reasonable for the macro writer to synthesize
Complex[Foo] by calling `inferImplicitValue(typeOf[Complex[Bar])`.

However if we didn't insert `info.sym.isMacro` check in `typedImplicit`,
then under some circumstances (e.g. as described in http://groups.google.com/group/scala-internals/browse_thread/thread/545462b377b0ac0a)
`dominates` might decide that `Bar` dominates `Foo` and therefore a
recursive implicit search should be prohibited.

Now when we yield control of divergent expansions to the macro writer,
what happens next? In the worst case, if the macro writer is careless,
we'll get a StackOverflowException from repeated macro calls. Otherwise,
the macro writer could check `c.openMacros` and `c.openImplicits` and
do `c.abort` when expansions are deemed to be divergent. Upon receiving
`c.abort` the typechecker will decide that the corresponding implicit
search has failed which will fail the entire stack of implicit searches,
producing a nice error message provided by the macro writer.