Use an intrinsic for the next power of two calculation and also return the input as is if it is already a power of two
blackbox and whitebox macros

This is the first commit in the series. This commit only:
1) Splits Context into BlackboxContext and WhiteboxContext
2) Splits Macro into BlackboxMacro and WhiteboxMacro
3) Introduces the isBundle property in the macro impl binding

Here we just teach the compiler that macros can now be blackbox and whitebox,
without actually imposing any restrictions on blackbox macros. These
restrictions will come in subsequent commits.

For description and documentation of the blackbox/whitebox separation
see the official macro guide at the scaladoc website:
http://docs.scala-lang.org/overviews/macros/blackbox-whitebox.html

Some infrastructure work to make evolving macros easier:
compile partest-extras with quick so they can use latest library/reflect/...
blackbox restriction #1: can't refine the official return type

When an application of a blackbox macro expands into a tree `x`,
the expansion is wrapped into a type ascription `(x: T)`, where `T` is
the declared return type of the blackbox macro with type arguments and
path dependencies applied in consistency with the particular macro
application being expanded.

This invalidates blackbox macros as an implementation vehicle
of type providers.
blackbox restriction #2: can't guide type inference

When an application of a blackbox macro still has undetermined type
parameters after Scala’s type inference algorithm has finished working,
these type parameters are inferred forcedly, in exactly the same manner
as type inference happens for normal methods.

This makes it impossible for blackbox macros to influence type inference,
prohibiting fundep materialization.
blackbox restriction #3: can't affect implicit search

When an application of a blackbox macro is used as an implicit candidate,
no expansion is performed until the macro is selected as the result of
the implicit search.

This makes it impossible to dynamically calculate availability of
implicit macros.
blackbox restriction #4: can't customize pattern matching

When an application of a blackbox macro is used as an extractor in a
pattern match, it triggers an unconditional compiler error,
preventing customizations of pattern matching implemented with macros.
Merge pull request #3129 from adriaanm/pr-rebase-3001

[rebase] blackbox and whitebox macros
Merge pull request #3127 from RajivKurian/OpenHashMap-nextPowerOfTwo-implementation

 Use an intrinsic for the next power of two calculation.
Fixes markdown syntax
Merge pull request #3142 from skyluc/bad-markdown-guidelines

Fixes markdown syntax