date.c: Don't use glib's slice allocator.

This change is gratuitous. For now, notmuch is still linking
against glib, so I don't have any requirement to remove this,
(unlike the last few changes where good taste really did
require the changes).

The motivation here is two-fold:

1. I'm considering switching away from all glib-based allocation
soon so that I can more easily verify that the memory management
is solid. I want valgrind to say "no leaks are possible" not
"there is tons of memory still allocated, but probably reachable
so who knows if there are leaks or not?". And glib seems to make
that impossible.

2. I don't think there's anything performance-sensitive about the
allocation here. (In fact, if there is, then the right answer
would be to do this parsing without any allocation whatsoever.)

date.c

@@ -115,8 +115,8 @@ typedef struct _date_token {
 	size_t len;
 } date_token;
 
-#define date_token_free(tok) g_slice_free (date_token, tok)
-#define date_token_new() g_slice_new (date_token)
+#define date_token_free(tok) free (tok)
+#define date_token_new() malloc (sizeof (date_token))
 
 static date_token *
 datetok (const char *date)