Suggested by Kostis.

Messages regarding guards with orelse/andalso could look
like "Clause guard cannot succeed. The variable A was matched
against the type any()". Now they look like as if or/and is
used: "Guard test is_integer(A::atom()) can never succeed".

erl_bif_types:type/5 was calling erl_types:map_pairwise_merge/3 directly
with its (potentially opaque) arguments, causing Dialyzer crashes.

Bug (ERL-249) reported and minimised test case provided by Felipe
Ripoll.

t_map/3 previously required callers to perform this normalisation, but
as t_from_form/5 would sometimes fail to do so, this requirement is
relaxed.

Bug (ERL-177) reported and shrunk by Luke Imhoff.

It is possible that '...' is added later (OTP 20.0), but for now we
are not sure of all details.

Opaque singleton keys have the unfortunate property, unlike any other
singleton type, to overlap with other singleton types that do not have
the same internal representation. Therefore, we must not keep opaque
singletons in the Pairs list in a map type.

t_subtract/2 would break its postcondition by always returning the
underapproximation none() when given a variable on the right hand side.

This broke map type parsing, since it relied on t_subtract/2 to tell it
when map keys would shadow each other.

Opaque keys in maps broke an assumption in
erl_types:mapmerge_otherv/3 (that the infinimum of a singleton type and
some other type would either be none() or that same singleton type),
causing a case_clause crash.

dialyzer_typesig:traverse/3 would perform an unsafe optimisation when
given a cons pattern that contained a map and could be folded into a
literal with cerl:fold_literal/1. In this case, when traversing the map
a type variable would be generated, but this variable would be dropped
by the erl_types:t_cons/2 constructor by in turn calling t_sup(),
producing the overapproximation any(). However, in this particular case,
dialyzer_typesig:traverse/3 is not allowed to overapproximate, since its
result is used in an EQ-constraint.

Although erl_types:t_tuple/1 does not overapproximate like t_cons/2,
which makes the bug unlikely to affect tuples too, the fix was
nevertheless applied defensively to the case of tuples as well.

Also, fix a bug where dialyzer_utils:refold_pattern/1 would generate
syntax nodes with two {label, _} attributes.