Round decimal division of tuple elements.

When performing tuple division, the floating point representation of
decimal divisors may yield surprising results.  For example, the
following expression

  >> 1.1.1 / 0.1

can return 9.9.9 or 10.10.10 depending on the host platform.

To address such discrepancies, `round(3)` before casting the result of
tuple element division to a `REBINT`; this should improve cross-platform
consistency.
Use R3's rounding implementation instead of round(3).

This should ensure greater portability as `round(3)` was standardised as
part of C99.
Reduce mem/time for boot and tighten up sizes (appears to fix MSVC build)
TO LOGIC! treats all non-none non-false values as true (CC #2055)
Permit SET-WORD! as the argument to COPY and SET in PARSE (CC #2023)
IF, EITHER, and UNLESS accept all values in then/else slots (CC #2063)
Per @earl, don't add R_ARG4 for IF/ELSE (which we don't like anyway)
Incorporate /ONLY option for suppressing conditional block evaluation.
Merge pull request #157 from hostilefork/streamline-boot

Reduce mem/time for boot (removes binary scrambler which is no longer necessary) and tightens up sizes.
If you use older C compilers, please let us know if this builds okay.
Merge pull request #104 from 0branch/tuple-div-rounding

Round decimal division of tuple elements. This submission fixes the main problem, but there could be a few edge case issues remaining as pointed out by Ladislav.
Merge pull request #165 from hostilefork/cc-wish-2023

Permit SET-WORD! as the argument to COPY and SET in PARSE (CC #2023). Solves a common problem of scoping locals within a PARSE.
Merge pull request #170 from hostilefork/cc-wish-2063

IF, EITHER, and UNLESS accept all values in then/else slots (CC #2063). Brian, back in the early days, we'd not even consider this, but with the progression of Rebol and how we expression meaning, it makes sense now to allow it. Thanks for the addition.
Style: don't use additional block scopes
Merge pull request #181 from earl/hostilefork-cc-wish-2055

Update of #164: Have TO LOGIC! 0 return true
Fix a regression in PARSE caused by 8db79a9

This fixes an operator precedence typo in the check for "not COPY or
SET" which causes a few regressions in PARSE.
Merge pull request #182 from earl/fix-pr165-parse

Fix a regression in PARSE caused by 8db79a9. Thanks for quick fix, and no worries. Parse is very tight code, and it's nearly impossible to make even small change without running extensive regression tests.
Merge mainline into community

This also forward-ports the Bytes_To_Long to Bytes_To_REBCNT rename to
the boot-related changes in src/core/b-init.c.

Conflicts:
	src/core/f-stubs.c