RFC3339 mentions in paragraph 5.1 that if certain conditions are
fulfilled, then sorting date and time strings results in a
time-ordered sequence. One of the conditions is that the strings must
have the same number of fractional second digits. This commits makes
sure this is indeed the case.

An external fun could inadvertently suppress warnings for
unused variables, such as in this example:

    bug() ->
        BugVar = foo(),
        if true ->
            fun m:f/1
        end.

There would be no warning that `BugVar` was unused.

The bug was introduced in ff432e262e652, which was the commit
that extended external funs to allow variables.

https://bugs.erlang.org/browse/ERL-762

The type `beam()` in the `beam_lib` module is confusing:

    -type beam() :: module() | file:filename() | binary().

It says that the module name can be used to identify the BEAM module
to be accessed, but passing in the module name only works if the BEAM
file is located in the current working directory because the module
is not searched for in the code path.

The reason that it is allowed to pass in the module name as an atom is
for backward compatibility. A long time ago, atoms instead of strings
were used as filenames. For that reason, `filename` and `file` still
accept atoms as filenames (although the practice is frown
upon). `beam_lib` accepts an atom as the filename for the same reason.

To remove the confusion, remove `module()` from the type and the
mention of it in the documentation. Code that uses an atom as a
filename will still work, but Dialyzer will issue a warning.

https://bugs.erlang.org/browse/ERL-696

* john/compiler/deterministic-paths/OTP-15245/ERL-706:
  compiler: Forward +source flag to epp and fix bug in +deterministic
  epp: Allow user to set source name independently of input file name

Note that this does *not* affect -include()'d files or the -file()
directive.

Document bit_size in match-specs and allow in fun2ms

It is already allowed in match-specs.

As a consequence of some refactoring (OTP-14983, option
'chars_limit'), the Format argument of io_lib:format() no longer
accepts binaries in lists in Erlang/OTP 21.0.

Note that if Format is not of type io:format(), control sequences in
Format are ignored. This can result in unpredictable behaviour if, for
example, the output of io_lib:format() is used as Format: if the
output happens to be a string(), then control sequences are
interpreted, otherwise not.

A check that Format is of type io:format() will likely be introduced
in Erlang/OTP 22.0. That will probably mean work for some users, but
considering how unpredictable io_lib:format() is, we should try to fix
that.