erts: Implement yielding for distributed send of large messages

Use same mechanism as term_to_binary to yield
while encoding large messages for distributed send.
erts: Yield in term_to_binary while copying large binaries

Applies also to distributed send.
erts: Remove unnecessary goto for fun encoding
erts: Yield in term_to_binary when encoding big maps
erts: Optimize some repeated calls to {E,W}STACK_PUSH
erts: Print that we are crashdumping earlier

Change so that we print that the we generating a crash dump
before we actually generate it. So that if a huge crashdump is
being dumped, the user knows that something is going on.
erts: getsockname is not allowed on non-bound sockets

This only produces an error on win32, but should not really be called
on *nix either.
erts: Fix ub in list_to_integer and bignum div
First attempt at adding a skel for -spec's

New skel adds a -spec for the function after point.
Add more tests of supervisor

Add tests of code_change/3 and error handling of supervisor flags.
Rebase supervisor

Remove duplicated code related to checking of supervisor flags.
configure.in: fix test == bashism
eldap: Add support for modifying passwords

This implements the LDAP Password Modify Extended Operation (RFC 3062)
with two new functions modify_password/3 and modify_password/4. The
former is for directly setting passwords, and the latter is for users to
change their own passwords.

Since all three parameters are optional, I've opted to support this with
the empty string rather than a property list. This seems consistent with
other functions in the module (i.e. modify_dn/5).
[sasl] Remove undocumented upgrade instruction

The upgrade instruction 'remove_module' was added in OTP R7B (and
possibly in a patch in R5B or R6B, ticket OTP-3477), and translates to
the low level instruction 'remove', but adds the parameter DepMods
(modules on which Mod is dependent). The ticket says that
"remove_module should be added for symmetry with the add_module
instruction". remove_module was never documented or tested, and it was
never mentioned in a release note. It therefore seems to be low risk
in removing it.

The correct instruction to use when removing a module is

{delete_module,Mod}

which was added in OTP R10B and which is also documented and
tested. This translates to low level instructions 'remove' and 'purge'
i.e. the module is brutally purged after setting the current code to
old. This hardcoded brutal purge is the reason why PrePurge and
PostPurge parameters can not be given with the delete_module
instruction.

The parameter DepMods which was inclued in the remove_module
instruction does not exist for delete_module. From the documentation's
point of view, this is the same for add_module, and thus the two
instructions {add_module,Mod} and {delete_module,Mod} are now
symmetric. However, in the code there is a second instruction for
adding a module, {add_module,Mod,DepMods}, which is not documented. To
add symmetry even for this, {delete_module,Mod,DepMods} is now also
added. Documentation is added for all instructions.
Allow maps for supervisor flags and child specs

Earlier, supervisor flags and child specs were given as tuples. While
this is kept for backwards compatibility, it is now also allowed to
give these parameters as maps:

-type sup_flags() :: #{strategy => strategy(),         % optional
		       intensity => non_neg_integer(), % optional
		       period => pos_integer()}        % optional

-type child_spec() :: #{id => child_id(),       % mandatory
			start => mfargs(),      % mandatory
			restart => restart(),   % optional
			shutdown => shutdown(), % optional
			type => worker(),       % optional
			modules => modules()}   % optional

Default values are as follows:

Supervisor flags:

strategy: one_for_one
intensity: 1
period: 5

Child specs:

restart: permanent
type: worker
shutdown: 5000 for workers, 'infinity' for supervisors
modules: [M], where M comes from the child's start {M,F,A}

Some of these default values are quite hard to decide on, since there
really is no "most common way". It always depends on the use case. So
we decided that the most important reason for having default values is
to lower the start barrier and get "something" running. For production
use, most systems must be fine tuned in this respect anyway.

This is how we reasoned about it:

Strategy: just pick one - and 'one_for_one' was most used in OTP.

Max restart frequency (intensity/period): by allowing one restart only
we keep the important supervisor feature of restarting children, but
we also avoid the possibility of scaling to a huge amount of restarts
if the supervisor tree is deep.

Restart: just pick one - and 'permanent' is fairly common.

Shutdown for workers: to avoid the confusion of why the terminate
function is not executed, we decided not to use 'brutal_kill'. Which
number to use is probably not that important, so we chose 5000.

Shutdown for supervisors: the recommended shutdown value for
supervisors is 'infinity', so we decied to use that. Having the same
(integer) value as for workers can give very strange results.

Type: just pick one - and we believe that 'worker' is most common
New function supervisor:get_childspec/2

Takes the name of the child (or Pid, in the case of a
simple_one_for_one supervisor) and returns the map which specifies the
child.
Merge branch 'rickard/eager-check-io/OTP-12117' into maint-r16

* rickard/eager-check-io/OTP-12117:
  Introduce support for eager check I/O scheduling
Prepare release
ssh: Add ptty_alloc/[2,3]
ssh: Add pty_alloc request to ssh:shell/[1,2,3]