For tidiness, always place .core files in data directories.

Use the same syntax for map pairs in Core Erlang code as in the
Erlang Code. This Erlang code:

  M#{x:=42,y=>1}

will look like this in Core Erlang:

  ~{'x':=42,'y'=>1|M}~

Ex.

Instead of:

    M~{~<K,V>}~

The format is now:

    ~{~<K,V>|M}~

This also removes a shift/reduce warning.

The changes in core_pp now requires compiler-5.0 to compile
because of is_map/1 guard, i.e. a need for a compiler with Maps know-how.

Expressions such as erlang:'or'(bar, true) can make beam_bool crash if it tries
to optimize them, as this code is not quite really written by users, no attempt
to rewrite them more efficiently should be done, for simplicity's sake.

Reported-by: Ulf Norell

Starting in e12b7d5331c58b41db06cadfa4af75b78b62a2b1,
sys_core_fold:eval_case/2 will crash on handwritten but legal
Core Erlang programs such as:

   case let <Var> = Arg in {'x',Var} of
      {x,X} -> X
   end

The problem is that the only clause *is* guaranteed to match, but
cerl_clauses:match_list/2 does not understand that; all it can say is
that the clause *may* match. In those circumstances, we will need to
keep the case.

Also make sure that we keep the case if the guard is something else
than 'true'. That is not strictly necessary, because in a legal Core
Erlang program the guard in the last clause in a case must always
evaluate to 'true', so removing the guard test would still leave the
program correct. Keeping the guard, however, will make it somewhat
easier to debug an incorrect Core Erlang program. (The unsafe_case
test case has guard test in the only clause in a case, so we don't
need to write a new test case to test that.)

Reported-by: Anthony Ramine

A guard with a sequence will cause a crash in v3_codegen. Currently,
it seems that a sequence in a guard will never happen when compiling
from Erlang code, but there are several reasons to fix this problem
anyway:

* There are other compilers that generate Core Erlang code.

* Changes to sys_core_fold (perhaps additional optimizations) may
  cause sequences to be generated in guards.

* A previously uncovered line in sys_core_fold:opt_guard_try/1 will
  now be covered.