Start implementations of <algorithm>, <array>, <iterator>, <utility>

[pfusik]

This reduces the list of errors in #52 to:

C:\0\a8\llvm>"install\bin\mos-c64-clang++.bat" -Os -Wall pong.cpp
pong.cpp:260:19: error: no member named 'make_tuple' in namespace 'std'
      return std::make_tuple(
             ~~~~~^
pong.cpp:295:31: error: no matching constructor for initialization of 'const std::array<Color, 16>'
  const std::array<Color, 16> colors = {{
                              ^        ~~
C:/0/a8/llvm/install/bin/../mos-platform/common/include/array:9:8: note: candidate constructor
      (the implicit copy constructor) not viable: cannot convert initializer list argument to 'const
      std::array<(anonymous namespace)::Color, 16>'
struct array {
       ^
C:/0/a8/llvm/install/bin/../mos-platform/common/include/array:9:8: note: candidate constructor
      (the implicit move constructor) not viable: cannot convert initializer list argument to 'std::array<(anonymous
      namespace)::Color, 16>'
C:/0/a8/llvm/install/bin/../mos-platform/common/include/array:9:8: note: candidate constructor
      (the implicit default constructor) not viable: requires 0 arguments, but 1 was provided
2 errors generated.

To be continued.

[ooxi]

What's the reason for not using libc++? At least the freestanding parts should work without modification, shouldn't they?

[mysterymath]

Do be aware that I'm planning to port libc++ itself at some point, and I'll end up replacing many of these functions with those

I'm definitely not going to block any work along these lines though; who knows what I'll actually get around to, and a bird in the hand is worth two in the bush. It's also very likely that hand-written 6502-friendly versions of various functions will be superior to those in libc++; in those cases; I'll try to port any of the work over as an #ifdef inside our fork of libc++.

[mysterymath]

Include guards rather than pragma once; here and throughout.

[pfusik]

Why?

[mysterymath]

Mostly straight conservativism; the majority of C++ style guides disallow it. In particular, it's not allowed in the LLVM style guide, which we've been taking as a baseline (although I've been nowhere near as picky about naming etc.) It's also generally desirable to use standardized mechanisms over non-standard ones, unless there's a very compelling reason.

[pfusik]

What's the reason for not using libc++? At least the freestanding parts should work without modification, shouldn't they?

I wanted to check what it takes to implement the library looking at the C++ standard. Also, I guess that writing just the parts needed for pong.cpp (#52) is less work than enabling libc++.