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
deduplicate tuple tree creation code

Previously tuple tree generation code has been implemented in
three place: tree builder, tree gen, build utils. Now it's just
defined once in tree gen.
make internal implementation of universe.build less restrictive

1. Use protected instead of private to avoid needless lock-in

2. Use BuildImpl field type to expose non-protected members to the
   compiler (user-facing side in the reflection api stays the same)
add hasAttachment utility method to the internal api
add some post-typecheck tests for quasiquotes

Typecheck trees with toolbox and check that they are still matched
by corresponding quasiquote. Fix tuples and function types matchers
to account for different shape of trees after typing.
simplify imports in quasiquotes scalacheck tests
add support for importable attachments

Previously attachments weren't imported by importTree. Now a new marker
trait has been added that lets attachments to import themselves to the
new universe together with all their innards. Additionally a simpler
subtrait is defined to mark attachments that can be imported as-is.
make fresh names compare similar in quasiquotes

Otherwise it's annoying that trees that look the same are not equal
due to some fresh name hidden underneath. Due to this one test needs
to be changed to use plain equalsStructure.
change intermidiate representation of for loop enumerators

Encode values into real trees rather than non-tree case classes.
This is needed for re-usability of desugaring code between quasiquotes
and parser.
move for loop desugaring into tree gen
add syntactic combinators that represent enumerators
implement inverse transformation to mkFor

This effectively reconstructs a sequence of enumerators and body
from the tree produced by mkFor. This lets to define bi-directional
SyntacticFor and SyntacticForYield constructors/extractors to work
with for loops.

Correctness of the transformation is tested by a scalacheck test
that generates a sequence of random enumerators, sugars them into
maps/flatMaps/foreach/withFilter calls and reconstructs them back.
add support for for loops and for enumerators to quasiquotes

1. q"for (..$enums) $body", q"for (..$enums) yield $body"

2. fq"..." quote to construct/deconstruct enumerators
re-implement hasAttachment directly in raw attachments
test legacy .filter support in for loop resugaring
add comments that explain new for loop enumerator encoding
add comments that explain FreshName extractor from Quasiquotes cake
Refactoring to prepare modularization of the compiler.

Actual modularization is delayed until 2.12.

The one big (one-line) change is to make the interactive compiler independent
of scaladoc. We have one "integration test": `MemoryLeaksTest`.

This commit adds a bunch of comments marked `TODO: modularize the compiler`,
that should be uncommented when we're ready to continue the modularization
effort.

I decided to merge them commented out to avoid having to rebase xml patches.
There's still some chance of bitrot, but I'm willing to take my chances.

I previously refactored the build to make it easier to add jars in a coherent
way, which hinges on the `init-project-prop` mechanism, so the relevant
properties are already injected there.
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.