The <c>size/1</c> BIF is not optimized by the JIT, and its use can
result in worse types for Dialyzer.

When one knows that the value being tested must be a tuple,
<c>tuple_size/1</c> should always be preferred.

When one knows that the value being tested must be a binary,
<c>byte_size/1</c> should be preferred. However, <c>byte_size/1</c> also
accepts a bitstring (rounding up size to a whole number of bytes), so
one must make sure that the call to <c>byte_size/</c> is preceded by a
call to <c>is_binary/1</c> to ensure that bitstrings are rejected. Note
that the compiler removes redundant calls to <c>is_binary/1</c>, so if
one is not sure whether previous code had made sure that the argument is
a binary, it does not harm to add an <c>is_binary/1</c> test immediately
before the call to <c>byte_size/1</c>.

OTP-18179

Add a --enable-deterministic-build to the configure script,
which sets ERL_DETERMINISTIC=yes throughout the relevant
Makefiles, which then invoke the relevant build stages with the
+deterministic option.

This addresses absolute paths being included in generated .erl files
and compiled .beam files that resulted in builds from different source
directories generating different artefacts (which is a component of the
issue in erlang#4482).

I think it would make sense to make this the default at some stage, but
I've put the change behind a flag for now to decouple
making deterministic OTP builds possible from making them the default.

Having +deterministic set results in compiler options being
removed from the module info for modules where this options was used.
This may have other implications for users of OTP.

For tests themselves, +determinism is not set, since many test cases
depend on accessing the test module's compilation options, or other
features not available in deterministic mode, in order to configure
themselves. For tests of the determinism feature specifically,
+deterministic must be explicitly passed to the compiler within the
relevant test cases.

* maint:
  Compile time no longer available

A few functions still attempted to extract the "compile time"
of each module. This info used to be available when calling
Module:module_info but was removed "a long time ago". A first
removal was done in OTP-15330 and this removes some remaining
leftover cases.