FIXME: update for v1.4.0

Rough description of the API:

Firstly, an excuse: it's not really that object-orientated, I'm just using
some handy features of C++ to get what otherwise is messy and verbose in C.
Unfortunately, that sacrifices the relative clarity of C headers with
tricky-looking C++ headers.

What I chiefly needed was a hassle-free correlation option, a revamped parser,
and a structure that can bear further development without turning into the
mess that C mdate became, not to mention overloading.

Overview of the overview:

Most code involves converting to/from a Julian Day Number (NOT fractional),
then converting the result into a string buffer, often preformatted. Use of
the JDN in converting between calendars is time-honoured; using string buffers
is great for GUI interfaces.

mdate.hh outline:

The global variables:
- Various i18n bits to later support wide-byte characters.
- A typedef Bool is safer for older compilers, but until someone actually
  needs this, I'm sticking with the c++ standard (as far as g++ goes).
- julian_date is used by everything to convert to/from dates. also used by
  the driver, so it's not static.
- corr is heavily used also by most functions and the driver.

There are a few public data members, intended mostly for possible future use:

julian::corr_set - used in julian::set_correlation(corr c). 
- since the parser can already check for this, it may go soon.

mdate::pflag 
- this was an obsolete method to control output, now recycled for similar
  reasons, but not so visible.

There are a few friends about, sorry about that. It was either make all data
members public (ugh) or force interface functions on other classes, which is
also wrong IMHO.

class mdate inherits from everywhere else, but also hosts some core methods as
they depend on accessing the parent classes. mdate also initialises all the
parent constructors.

The various *date classes are self-explainatory, class julian is interesting
because it deals with the correlations. Our standard (584285) is the
Loundsbury Correlation (after Floyd Loundsbury, with whom most Mayan scholars
violently disagree, probably because he was right), and I give a nod to the
GoodMan-Martinez-Thompson standard (GMT), which isn't as rock-solid as many
would have you believe. There's also a roll-your-own option for those who
disagree with everyone (anyone worked out what the hell the dreamspell people
think it is?!) :)

New to versions beyond 1.4.0: gregdate's data field has been expanded to
support a date(1)-like strftime format function (see
gregdate::gregdate_sstr()). It still does not, nor ever will, support time of
day formatting.

The various string output functions are overloaded to make choosing output
formats more easily. This will become more important in the near future.

mdate.cc outline:

The AMOD(x,y) macro ensures positive moduli in certain situations. It's only
used in one place, don't panic.

David Starner kindly wrote a C version of BSD drem(). I should explain why
it's used at all: fmod() discriminates between +ve and -ve numbers, drem()
doesnt, which is important when you're taking a modulus from floating-point
numbers. It surprises me that it's seen so rarely, it's so useful. Of course,
some *nix'es decided to call it remainder() to avoid that BSDish taint from
their otherwise pristine SYSV flavour. And some have never heard of it. So
my_mod() tries to cope with it all in one go.

The two most important functions convert JDN's to Gregorian dates and vice
versa. Many, many people have tried this and everyone disagrees with everyone
else's code. For much of mdate's life I used Ivan Van Langingham's python
functions translated to C. Since then, I've been reacquainted with the public
domain Fliegel/Van Flandern algorithms which are fine as I don't use
fractional JDN's which are more in line with the more academic uses of Mayan
calendars. Since such dates are of the most obscure academic use, academics
probably have far superior programs for that.

Most of the string functions are overloaded for formatting purposes.

The gregdate string functions have a GNU-specific quirk; either strftime() is
different, or the non-constant gtm structure is allowable. This certainly
didn't work the last time I tried compiling this function with Borland C/C++,
it may not work with other compilers/systems. 

Every attempt has been made to avoid language-dependent code in this module,
but there are obviously issues with gregdate_ordstr(). The tzolkinmonth_* and
haabmonth_* functions have hardcoded strings in them; the "old" Romanisation
of Mayan names. It might be nice to allow the other variant spellings of
these, but that will have to wait for other functionality and user demand. 
