Extending timeclock.el

[John Task]

Hello.  A little context, first; some days ago, I submitted a request
for including a package in the NonGNU ELPA repository.  The package in
question was a time tracker named ETT.  However, Eli pointed out that
instead of creating a new package I could, for instance, extend the
built-in timeclock.el instead.  To be honest, I didn't like the idea
at first, but looking at the code I quickly realized it wouldn't be
that hard.  At least, not as dramatically hard as I thought.

So I started this: https://gitlab.com/q01_code/timeclock-modern

[This wasn't my first name choice, but turns out timeclock-x is
already taken]

So far, I managed to write a series of parsers for the timelog format,
as well as a basic API for retrieving information from it.  This
should allow me to port all the relevant code from ETT without issues.
However, I'm not really familiarized with timeclock, so I can't assert
my design choices so far have been ideal.

+ The letter code at the start of every line was the most difficult
part.  ETT (and a lot of modern time trackers as well) don't
understand what clock-out means, as the idea is to clock everything;
the user just clocks-in different activities.  So, I dropped 'i' and
'o' for my custom tm-clock-in altogether.  As for the parser, it
understands 'o' as the start of a so-named 'Untracked' item/project.
That way it can read existent timelogs just fine.  This is hard
enough, but turns out there are also other codes ('h', 'b' and '0').
I interpret '0' as an 'o' and ignore the other ones, but I'm not sure
if this is correct.

+ As I make a lot of decisions such as the last one from ignorance,
I'm clueless about how well the parser (and the API) works for real
timelog files.  If anybody wants to test that, it would be
appreciated.

+ As the original timeclock-in doesn't support inputting tags (as well
as other features I need), I wrote a custom tm-clock-in.  But I'm not
sure if this is the right approach.  And redefining timeclock-in would
be even worse, for sure.

I'll eventually contact the original author as well, but I wanted to
know of any other opinions here first.

Best regards.