Move Au code into code/au subfolder (#266)

This replaces the `project_symlinks` approach we had been using for
CMake: it turns out that symlinks are fraught and error prone on
Windows.  After this PR, CMake support on Windows is confirmed to work!

To make this work, we had to satisfy a number of challenging
constraints:

1. The include path had to be `"au/..."` (e.g., `"au/io.hh"`) for all
   files, on both bazel and CMake.

2. The `au` folder that contained the actual code needed to live inside
   of a true subdirectory --- not the git repository root folder (as it
   has been since time immemorial), and not a symlink (as we had been
   using to get CMake support).

3. The git repository root folder needed to also be the root of the
   bazel folder, because we use that for all of our bazel-backed tools,
   and because we want users to be able to run all `bazel` commands from
   the repo root.

I previously tried a variety of approaches here, including:

- Having CMake create the symlink, instead of having it checked in (bad
  idea: you can't create symlinks in Windows without developer mode).

- Making a `code` subfolder in the git repository root that had _its own
  separate `WORKSPACE` file_, and was included as a local bazel repo
  (terrible idea: we'd need two copies of all auxiliary bazel files, and
  making the single-file script work was nightmarishly complex --- I
  never even fully got there).

In the end, the approach that works is to use the `includes` attribute
of the `cc_library` rule.  This is simple and direct: it's designed to
solve this exact problem.  The only real downside is that we need to
prepend `code/au` to a lot of files in the `BUILD.bazel` for `//au`, and
also in a couple of places in the single file script.

Helps #215.

CMakeLists.txt

@@ -55,7 +55,7 @@ set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
 FetchContent_MakeAvailable(googletest)
 include(GoogleTest)
 
-add_subdirectory(cmake/project_symlinks)
+add_subdirectory(au)
 
 # Configure how Au will be installed.
 #