Improve code for integral modulus calculation.

Depending on what we know about the right operand, we basically do 3
different things (and the code is actually structured this way):

* If we statically know that the right operand is a power of 2, we do
  some bit fiddling instead of doing a "real" modulus calculation.
  This should actually be done on the Hydrogen level, not on the
  Lithium level, but this will be a separate CL.

* If type feedback tells us that the right operand is a power of 2, we
  do the same as above, but guarded by conditional deoptimization to
  make sure that the assumption is still valid. In the long run, we
  should make this guard visible on the Hydrogen level to make it
  visible for GVN and other optimizations.

* In the general case we only do the minimum steps necessary and don't
  try to be too clever, because cleverness actually slows us down on
  real-world code.

If we look at the code gerators for LModI, we actually see that we
basically have 3 (4 on ARM) fundamentally different translations. I
don't really like lumping them together, they should probably be
different Lithium instructions. For the time being, I restructured the
generators to make this crystal-clear, at the cost of some duplication
regarding the power-of-2 cases. This will go away when we do the
strength reduction on the Hydrogen level, so I'd like to keep it as it
is for now.

Note that the MIPS part was only slightly restructured, there is still
some work to do there.

R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/15769010

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@15034 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Don't fuzz _GeneratorNext

The previous patch that renamed _GeneratorSend to _GeneratorNext missed
the blacklist in fuzz-natives-part4.

R=mstarzinger@chromium.org
BUG=

Review URL: https://codereview.chromium.org/16339008

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@15035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00