Use David M. Gay's dtoa for molding decimals

Currently, R3 uses platform-specific code for molding decimal numbers.
This increases the effort necessary to port to new platforms like
android-arm or linux-arm

Porting R3 to android-arm we found none of the system-specific methods
currently used by R3 were available. Instead of adding another
system-specific method specifically for android-arm, we decided to
replace the system-specific methods using the dtoa function
implementation by David M. Gay.

David M. Gay's original code is available at:
http://www.netlib.org/fp/dtoa.c

This implementation brings the following advantages:

- MOLD and MOLD/ALL results will be accurate (solving cc#897).
- MOLD results will be consistent across wide range of platforms
  (solving cc#1633).
- MOLD results will be optimal: yielding the shortest string that can be
  used to reproduce the number (i.e. a string that is accurate enough).
- Makes porting to new platforms easier.
- Battle-tested solution, as this is the way how the problem was solved
  in e.g. Java, Javascript, Python, Firefox, Chrome.

The commit makes the following changes:

- David M. Gay's implementation is added as src/core/f-dtoa.c. The
  source is unmodified except for an #include of Rebol-specific
  configuration and a reference to where the source was downloaded from.
- An attribution notice is added to NOTICE.
- Configuration for f-dtoa.c is contained in src/include/reb-dtoa.h.
- The additional source is listed in src/tools/file-base.r.
- make/makefile is re-generated to accommodate the additional source.
- The HAS_ECVT, HAS_LOG10L, HAS_LONG_DOUBLE Rebol configuration defines
  are removed as they are no longer necessary.
- HAS_LL_CONSTS was previously implied by HAS_LONG_DOUBLE; it is now
  defined explicitly for the respective platforms.
- Functions for decimal conversion are modified to use dtoa.

This resolves CureCode issues 897, 1633, 1942.
Fix value returned by SELECT with a series argument

Currently SELECT ignores what type of value was used for selection, and
always returns the second value from the start of the match. This
behaviour is correct when selecting with atomic values:

    >> select [1 2 3 4] 1
    == 2

But breaks when selecting with compound values:

    >> select [1 2 3 4] [1 2]
    == 2  ; Expected: 3

    >> select "1234" "12"
    == #"2"  ; Expected: #"3"

This commit fixes the incorrect calculation of the offset of the value
to be returned by taking the length of the match value into account.

This fixes CureCode issue 1936.
Update src/core/s-trim.c

2013.02.02 by CCX (cc@x.isla.pr)

>> trim "  x ^/"
== "x x^/"

Fixed that trim bug, found in trim_head_tail(). Changed some var
names and the function declaration to make easier to understand
the algorithm. Now head and tail are trimmed first because its
simpler that way.

First time I ever use github...
Trim that Bug! (minor tweaks)

• Removed useless `const` from function declaration (suggested by hostilefork.)
• Removed unnecessary in-source change log.
Update src/core/s-trim.c
Fix recursive make calls

Instead of hardcoding the name of the make command, use the predefined
$(MAKE) variable for recursive make invocations.

This fixes the build for environments where make is called something
else (like `gmake`, or `mingw32-make`). $(MAKE) is standardised in
POSIX's make specification and present in at least GNU make and BSD
make.

Problem most recently brought to attention by Adrian Sampaleanu.
Fix crash when accessing an empty but hashed map

A map! internally switches to a hashed implementation if the map holds
more than a given number of items. If a map becomes empty again after
having switched over to hashing, lookups on the empty map lead to a
division by zero (in modular arithmetic), crashing the interpreter.

This commit fixes the division by zero crash by side-stepping modular
arithmetic for the special case of an empty map.

The problem was originally identified by user HostileFork on Stack
Overflow chat.

Fixes CureCode issue #1930.
Make APPLY secure against RETURN/redo (#1949)

You can break through APPLY security with RETURN/redo or native code
equivalent to that, code which is not buggy or bad in itself.

The APPLY native should clear the OPTS_REVAL flag from its return value
before it returns. The native itself, not Apply_Block in case it is used
elsewhere internally in cases where OPTS_REVAL would be OK. It is only
in calls to the native APPLY that it is a problem.

Current behavior
>> apply does [return/redo :add] [] 1 1
== 2

Preferred behavior
>> same? :add apply does [return/redo :add] []
== true

See http://issue.cc/r3/1949
bug#1956
bug#1955, updates of malconstruct error and mold help string
help strings of ASSERT and TRANSCODE
bug#1844, modification properties
bug#1958, BIND and UNBIND can work on blocks not containing (just) words
bug#1957 corr, FIRST+ help strings updated
Fix PARSE regression: THRU not matching at the end

Commit 44012cc1e7313f2fd3772e543f2f8b9096d90f9c introduced a regression
that causes THRU rules to fail when it matches to the end of input. A
simple test case illustrating the regression:

    >> parse "abcd" [thru "d"]
    == false  ;; Expected: true

Internally, this is caused by a left-over check that was previously used
to handle not-found results from the internal Find_* helpers. This check
tests against past-or-on (>=) end position, which is now wrong, because
THRU positioning happens before the check occurs and it is perfectly
valid for THRU to advance _to_ end position. So if anything, we'd have
to relax that check to test against past (>) end position. But even that
is not needed, because this check is no longer necessary at all, as all
matching branches correctly check on their own for NOT_FOUND results.

There is one occurrence of the "old" pattern for testing against
NOT_FOUND left in the Parse_To function. This will be corrected for
consistency in a follow-up commit.

The regression was originally reported by Boleslav Brezovsky on AltME.

This fixes CureCode issue #1959.
Improve consistency of NOT_FOUND/THRU handling in Parse_To

Use the "new" style of handling NOT_FOUND in combination with THRU
positioning also for the block! parsing case. This relies on the fact
that Find_Block does (a) not position past tail when it matches, (b)
returns NOT_FOUND when it fails to match.

The old check (`i >= series->tail`) worked because of signed/unsigned
integer arithmetics: `i` is unsigned, `NOT_FOUND` is defined as `-1`, so
`i = NOT_FOUND` wraps around to an `i` that is `>= series->tail`. So in
combination with the fact that Find_Block doesn't position past the end,
the old check is effectively equal to `i == NOT_FOUND`. This is made
explicit by the new implementation.

The same handling of NOT_FOUND/THRU is already used in the other cases
of Parse_To (string+string, string+char).
Fix SET object/block block assuming /any (#1763)

SET without /any wasn't triggering the error it should have when
assigning a block of values that include unsets to a block or an
object. This tests for that condition and triggers the error before
even a single assignment happens, all or nothing.

See http://issue.cc/r3/1763 for the ticket.

Also added documentary comment about new unwind policy. The unwind
screening required to fix http://issue.cc/r3/1515 must be performed
elsewhere, in Set_Var, Do_Next and other related functions, for it
to work properly. Not practical to put the fix here.
Make build platform handling more robust

Change platforms.r to use pairs of "minor" platform number and value.

Add the Android platform as well as old R2 platforms.

Adapt make-boot.r accordingly.

Add a sanity check for the existence of a platform.

Fix handling of the "system/product" name.

This contribution was originally written by Richard Smolak.
Fix clipboard device code so it works identically under non-wide-char platforms

This contribution was originally written by Richard Smolak.
Fix PARSE `THRU integer` operation

PARSE's `TO integer` operation positions "at" the given index. In line
with how PARSE's TO/THRU relate otherwise, `THRU integer` should
therefore move to the position "next" to the given index:

    >> parse "abcd" [to 2 (comment {Positions to "bcd".}) "bcd"]
    == true

    >> parse "abcd" [thru 2 (comment {Should position to "cd".}) "cd"]
    == false  ;; Expected: true

This commit adds the missing handling for distinguishing THRU from TO
in the case handling `TO/THRU integer` operations.

This fixes CureCode issue #1965.