Previously, the buffer was increased linearly by 2048 bytes.
I now propose to use an exponential increase function
(similar to Javas ArrayList, e.g. always at least +50%).
This significantly increases performance of e.g. doRPC for
large parameters as the following comparison illustrates
(shown is the buffer size after each time, the buffer has reached its limit):

n    n*2048       (n*3)/2+1    (n*3)/2+1 (at least +2048)
1     2,048           2,048          2,048
2     4,096           3,073          4,096
3     6,144           4,610          6,145
4     8,192           6,916          9,218
5     10,240         10,375         13,828
6     12,288         15,563         20,743
7     14,336         23,345         31,115
8     16,384         35,018         46,673
9     18,432         52,528         70,010
10    20,480         78,793        105,016
11    22,528        118,190        157,525
12    24,576        177,286        236,288
13    26,624        265,930        354,433
14    28,672        398,896        531,650
15    30,720        598,345        797,476
16    32,768        897,518      1,196,215
17    34,816      1,346,278      1,794,323
18    36,864      2,019,418      2,691,485
19    38,912      3,029,128      4,037,228
20    40,960      4,543,693      6,055,843
21    43,008      6,815,540      9,083,765
22    45,056     10,223,311     13,625,648
23    47,104     15,334,967     20,438,473
24    49,152     23,002,451     30,657,710
25    51,200     34,503,677     45,986,566
26    53,248     51,755,516     68,979,850
27    55,296     77,633,275    103,469,776
28    57,344    116,449,913    155,204,665
29    59,392    174,674,870    232,806,998
30    61,440    262,012,306    349,210,498

Actually, ArrayList uses the (n*3)/2+1 strategy. In order not to
decrease performance for messages <10k, we could keep the (public)
OtpOutputStream#defaultIncrement constant and let the buffer always
increase by at least this much (third column).

In order to create a buffer of 1MB, now only 16 array copies are
needed vs. (1024*1024/2048)=512 array copies for the linear increase
function. If a user sends a message of 10MB size, this is 22 vs.
5120 copies.

NOTE: the meaning of the "public static final int defaultIncrement"
member has changed a bit with this implementation (API compatibility?)
- why was this public in the first place?

This reverts commit e21ff9b0b69219ab3853be7e80813156113152b7.

These dependency files was once used when building the documentation,
but are no longer needed.

The two noncharacter code points 16#FFFE and 16#FFFF were not
allowed to be encoded or decoded using the unicode module or
bit syntax. That causes an inconsistency, since the noncharacters
16#FDD0 to 16#FDEF could be encoded/decoded.

There is two ways to fix that inconsistency.

We have chosen to allow 16#FFFE and 16#FFFF to be encoded and
decoded, because the noncharacters could be useful internally
within an application and it will make encoding and decoding
slightly faster.

Reported-by: Alisdair Sullivan

There once was a reason to have a "Makefile.otp" makefile, but
it doesn't apply any longer.  Rename it to "Makefile" so that
the standard otp_subdir.mk file can be used for recursion into
sub directories.