Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>

Seems that the Python C extensions were being
(or at least trying to be) build using '/usr/include' as the first
include folder.

Seems this issue was already fixed on MacOS X and now we've extended
it for our case.

Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>

According to PEP394 (http://legacy.python.org/dev/peps/pep-0394/)
the 'python' command should refer to 'python2'.

In our case, this means we should reboot the old python package.

We could rename the package name to python2, but that would
just complicate things a bit with other packages, and
since we're doing this reboot, such a complication would be
unnecessary.

Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>

Some notes:
- Python 3 (at least version 3.4) is pretty cross-compiler-friendly,
  so a lot of patches were thrown away.
- Arguments below were moved to ./files/config.site file, and disabled
      ac_cv_have_chflags=no \
      ac_cv_have_lchflags=no \
      ac_cv_py_format_size_t=no \
      ac_cv_have_long_long_format=yes \
      ac_cv_buggy_getaddrinfo=no \
- --without-ensurepip added, because the build wants to ensure that
  it works; that's a good idea, but for now, it requires special
  setup, and we can do that later
- --without-pymalloc added, becase in Python 3, modules are suffixed
  with m; e.g. so some paths are python3.4m instead of python3.4
  all this is detailed here:
         http://legacy.python.org/dev/peps/pep-3149/
  Maybe it will be a good idea to re-add this back

Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>

Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>