The function allows it, only the spec didn't.

Consider a function spec:
    -spec negate(bool()) -> bool();
                (integer()) -> integer().

Sometimes, we want to make a single function type out of these two clauses.
Using an outer union like fun((bool()) -> bool()) | fun((integer()) -> integer())
leads to a loss of precision, because this type says that we either have
a function that can take a bool, or we have a function that can take an integer
(and we do not know which case it is). This means that we cannot apply a function
of this type to anything unless we assert type or something like that.

But we know for sure that it can take both, bools and integers! Therefore, using
an inner union like fun((bool() | integer()) -> bool() | integer()) seems better
to me as this way we know that it can take both.

Of course, an ideal solution would be to use intersection types like
fun((bool()) -> bool()) & fun((integer()) -> integer()), but Erlang doesn't have
them in its syntax and so don't we in Gradualizer.

Union function types (`fun_ty_union`) do not seem to work. These simple
examples should be perfectly valid. I think it throws that error because
`expect_fun_type/3` inputs a list of function types (i.e., a clause),
containing only a single element (the union of two function types).
This leads to expecting an intersection function type later on
(which is wrong).

Note that these union function types aren't that much useful in practice
as when you want to call them, all your argument types must be subtypes
of parameter types of all the possible function types. That is, when
you have a function of the type
    fun((integer()) -> integer()) | fun((atom()) -> atom())
then you can only call it with `none()` as we don't know whether the
function will accept integers or bools and no other type is a subtype
of `integer()` and `atom()`.

We use the Local Type Argument Synthesis algorithm from
https://www.cis.upenn.edu/~bcpierce/papers/lti-toplas.pdf
(a bit extended for our use case).

This replaces the global constraint generation and constraint
solver. It should result in a much more precise type error
messages (pinpointing the exact location, not just the
function) and more streamlined code (refactor will be made
in a subsequent commit).

For more details, see the original paper or
https://github.com/josefs/Gradualizer/wiki/Polymorphism#typechecking-polymorphic-calls

The following type spec from gradualizer_db uses a type variables (K)
as a bound for another type variable (Key):

    -spec add_entries_to_map([{Key, Value}], #{K => V}) -> #{K => V}
                                             when Key :: K, Value :: V.

Until now, we converted all Ks and Vs to rigid vars, but then Key
and Value got replaced to plain vars K and S in solve_bounds/2.

We must therefore convert the type variables to rigid type variables
*after* the call to solve_bounds/2, which is what this commit does.

Flexible type variables may now appear only when typechecking a polymorphic call,
in which case they are only in the type of that polymorphic function. No other
expression may of be a type that contains a flexible type variable. Constraints
are thus needed only in the subtype_with_constraints/3 function that gets called
only from type_check_poly_call/4. This means that nothing but the subtyping
functions and the type_check_poly_call/4 function needs to deal with constraints.
Therefore, I am removing constraints from all the other places.

I believe this is a great simplification of the code. It also trivially solves
all the TODOs like "Don't drop the constraints".

In such a huge refactoring, Gradualizer has proved to be an invaluable help.
Via self-gradualization, it discovered numerous errors that I didn't notice.
Hopefully, there are no undetected errors left. All tests are passing, the
self-gradualization does not crash and 100_000 proptests have also passed.

And also remove the assert_type uses that were needed because of this error.

This quite a trivial change enables us to typecheck polymorphic
functions like

    -spec generic_hd([A,...] | {A, any()}) -> A.

or functions from Elixir's Enum module that use protocol
polymorphism in addition to the parametric polymorphism:

    -spec enum_map([A] | map(), fun ((A) -> B)) -> [B].

which is really handy for Gradient and other Elixir frontends!

Support for intersection polymorphic functions like

    -spec generic_hd([A,...]) -> A;
                    ({A, any()}) -> A.

is of course still missing. But at least some of these can now
be typechecked when using a spec with the unions.

Since now we do not generate type variables,
they don't need to be strings anymore.

It is already there since December 2022 (unless "subtype polymorphism"
means bounded quantification).

They probably originate from the `fmt_location` description
that uses hyphens to list possible values.

Removes the hyphens and add `--solve_constraints` flag.

lists:uniq/1 was introduced in OTP 25.