remove '-I.', and include headers using the relative path

[elliefm]

I started this a long time ago, in 39dab7c, because our generated headers need their directory to be explicit to be correctly found during certain types of builds (which make distcheck checks, and therefore we need to succeed).

And it's fine having that comment in files that need those headers, but every so often we need to add a generated header to a file that doesn't already have any, and this detail gets missed and breaks distcheck again.

We can avoid tripping over this repeatedly by removing -I. completely, and updating every file to name its includes explicitly.

[elliefm]

We have ~50 (by crude search) source files that #include <assert.h> (i.e. using angle brackets) instead of #include "assert.h" (double quotes).

At the moment, they get the correct assertions (ours) because of our abuse of -I. When we fix this issue, those source files will start using the wrong assertions (stdc) instead of ours.

So, as part of fixing all the #include "foo.h" lines to be #include "path/foo.h", we'll also need to fix up the #include <assert.h> lines to be #include "lib/assert.h" too.

[elliefm]

WIP branch here (nothing to see yet): https://github.com/cyrusimap/cyrus-imapd/compare/master..elliefm:cyrus-imapd:v39/3044-include-cleanup

[elliefm]

This gets more complicated, because some headers get installed so that other code can be linked against libcyrus et al. These headers get installed to wherever they get installed to, with no extra lib/ subdirectory. If the installed headers include other installed headers by spelling it like #include "lib/foo.h", included header will not be found -- since it is not in a lib/ subdirectory relative to the first one.

So, even though spelling these includes as #include "lib/foo.h" works during a normal Cyrus build, it makes the headers that use that spelling unusable to other projects.