Signed-off-by: Rahix <rahix@rahix.de>

Building mpy-cross automatically leads to some issues with the build
process and slows it down.  Instead, require it to be built manually.

This change makes it so that python3 is required by default to build
MicroPython. Python 2 can be used by specifying make PYTHON=python2.

This comes about due to a recent-ish change to PEP 394 that makes the
python command more optional than before (even with Python 2 installed);
see https://github.com/python/peps/commit/cd59ec03c8ff1e75089d5872520cd0706774b35b#diff-1d22f7bd72cbc900670f058b1107d426

Since the command python is no longer required to be provided by a
distribution we need to use either python2 or python3 as commands.  And
python3 seems the obvious choice.

Since 0be2ea50 axtls is automatically built
as part of the usual "make" build process.

gcc is required for mpy-cross, and arm-none-eabi-newlib for ports using
arm-none-eabi-gcc.

To increase visibility of Contributors' Guidelines and Code Conventions
docs.

Given that various ports now require submodules, rewrite the section
to be more generic.

Also, add git submodule update command to other sections for easy user
start.

Also renames "stmhal" to "stm32" in documentation and everywhere else.

Link references don't seem to work anymore.

The issue-stats service is not well maintained and likely the situation
won't improve in the future.  See:
https://github.com/hstove/issue_stats/issues/41
https://github.com/hstove/issue_stats/issues/46

"make deplibs" also builds libffi, and that requires GNU autotools. As
we use host libffi by default, skip requiring users to build it for now.

tools/pydfu.py is now the recommended way of deploying a DFU file.  Old
behaviour of dfu-util can be obtained by passing USE_PYDFU=0 when invoking
make.

The main README.md file has been updated to reflect this change.

Also, hint about possibility to adjust heap size.

unix-cpy was originally written to get semantic equivalent with CPython
without writing functional tests.  When writing the initial
implementation of uPy it was a long way between lexer and functional
tests, so the half-way test was to make sure that the bytecode was
correct.  The idea was that if the uPy bytecode matched CPython 1-1 then
uPy would be proper Python if the bytecodes acted correctly.  And having
matching bytecode meant that it was less likely to miss some deep
subtlety in the Python semantics that would require an architectural
change later on.

But that is all history and it no longer makes sense to retain the
ability to output CPython bytecode, because:

1. It outputs CPython 3.3 compatible bytecode.  CPython's bytecode
changes from version to version, and seems to have changed quite a bit
in 3.5.  There's no point in changing the bytecode output to match
CPython anymore.

2. uPy and CPy do different optimisations to the bytecode which makes it
harder to match.

3. The bytecode tests are not run.  They were never part of Travis and
are not run locally anymore.

4. The EMIT_CPYTHON option needs a lot of extra source code which adds
heaps of noise, especially in compile.c.

5. Now that there is an extensive test suite (which tests functionality)
there is no need to match the bytecode.  Some very subtle behaviour is
tested with the test suite and passing these tests is a much better
way to stay Python-language compliant, rather than trying to match
CPy bytecode.

Also, simplify dependencies info now that we no longer require GNU
readline.