The include_guard in both regex and utime was "_TEMPLATE_H", this meant that including both wasn't possible.
Their header guards should be consistent with the header files as well.
Changed _TEMPLATE_H to _REGEX_H and _UTIME_H in /regex/cbindgen.toml and /utime/cbindgen.toml respectively.

Implemented the following calls according to http://pubs.opengroup.org/onlinepubs/7908799/xsh/libgen.h.html
- char* basename(char*)
- char* dirname(char*)

Added test suit for the implemented calls.

Issue: redox-os/relibc#134

Handle getopt reinitialization

See merge request redox-os/relibc!174

Disable symbol mangling for C++

See merge request redox-os/relibc!173

Fix assert when used as an expression

See merge request !172

Based on what musl does.

Don't drop the host aliases pointer vector in `gethostent`

Closes #130

See merge request redox-os/relibc!170

Implement almost all of printf

See merge request !171

There are pointers to this vector in `HOST_ENTRY` so we must keep it around for
as long as `HOST_ENTRY` exists.

wow i am stupid for writing this code

Huge thanks to @xTibor for both discovering that this was still an issue, and also providing information with how to fix it

Add tests for constructors and destructors

See merge request !169

Move regoff_t to regex.h

See merge request !168

Optimise `memcmp` for speed

See merge request !167

As per the comments from jD91mZM2 on the merge request.

Make assert more hygienic

See merge request !166

For some reason, C handles `==` before `&`.
So `a & b == c` is the same thing as `a & (b == c)`.

Accidentally made file references not count as references and therefore also close the fd. My bad.

I saw that in other parts of the `string` module iterations over `usize` were
used to increase iteration speed.  In this patch I apply the same logic to
`memcmp`.  With this change I measured a 7x speedup for `memcmp` on a ~1MB
buffer (comparing two buffers with the same content) on my machine (i7-7500U),
but I did not do any real world benchmarking for the change.  The increase in
speed comes with the tradeoff of both increased complexity and larger generated
assembly code for the function.

I tested the correctness of the implementation by generating two randomly filled
buffers and comparing the `memcmp` result of the old implementation against this
new one.

I ran the tests and currently currently three of them fail:
  - netdb (fails to run)
  - stdio/rename (fails to verify)
  - unistd/pipe (fails to verify)

They do so though regardless of this change, so I don't think they are related.