Replace nearly all XXX0vv comments with smarter ones

So, back long ago, XXX012 meant, "before Tor 0.1.2 is released, we
had better revisit this comment and fix it!"

But we have a huge pile of such comments accumulated for a large
number of released versions!  Not cool.

So, here's what I tried to do:

  * 0.2.9 and 0.2.8 are retained, since those are not yet released.

  * XXX+ or XXX++ or XXX++++ or whatever means, "This one looks
    quite important!"

  * The others, after one-by-one examination, are downgraded to
    plain old XXX.  Which doesn't mean they aren't a problem -- just
    that they cannot possibly be a release-blocking problem.

1 files changed, 5 insertions, 4 deletions

diff --git a/src/common/procmon.c b/src/common/procmon.c
index 12d53fcd41..4ecee26e8d 100644
--- a/src/common/procmon.c
+++ b/src/common/procmon.c
@@ -116,11 +116,11 @@ struct tor_process_monitor_t {
    * periodically check whether the process we have a handle to has
    * ended. */
   HANDLE hproc;
-  /* XXX023 We can and should have Libevent watch hproc for us,
-   * if/when some version of Libevent 2.x can be told to do so. */
+  /* XXXX We should have Libevent watch hproc for us,
+   * if/when some version of Libevent can be told to do so. */
 #endif
 
-  /* XXX023 On Linux, we can and should receive the 22nd
+  /* XXXX On Linux, we can and should receive the 22nd
    * (space-delimited) field (‘starttime’) of /proc/$PID/stat from the
    * owning controller and store it, and poll once in a while to see
    * whether it has changed -- if so, the kernel has *definitely*
@@ -130,7 +130,8 @@ struct tor_process_monitor_t {
    * systems whose admins have mounted procfs, or the start-time field
    * of the process-information structure returned by kvmgetprocs() on
    * any system.  The latter is ickier. */
-  /* XXX023 On FreeBSD (and possibly other kqueue systems), we can and
+
+  /* XXXX On FreeBSD (and possibly other kqueue systems), we can and
    * should arrange to receive EVFILT_PROC NOTE_EXIT notifications for
    * pid, so we don't have to do such a heavyweight poll operation in
    * order to avoid the PID-reassignment race condition.  (We would