Removed perf. fix because of a bug

I'll live with the slow performance for now; I need to figure out a
better way to improve performance.
README update and version bump

Now that the blog indexing feature is added I think it calls for a
version bump, and the README was updated to take the progress of the
tool into account.
Document template variables

It might be a good idea if people knew what variables they could use for
their templates!
Add more vars for the templates

Now you can reference the latest post, a subset of post, and the entire
blog index (no pagination yet):

{{blog_posts}} - A short list of posts (default 5)
{{blog_index}} - The whole list of posts

Each post has the following vars to use:

{{id}} - The slug/title
{{date}} - The creation date
{{{post}}} - The actual post content (triple {{{ for including html)
{{link}} - The relative URL to this blog post for linking to it.

Also fixed a bug with the stale file check where it would error if you
tried to reference blog posts when no blog posts were rebuilt. Now it
will correctly populate the post variables even if they remain
Add a simple way of listing all blogs

dtt build accepts an argument that is the number of blog posts to list
inside the blog_posts variable (defaults to 5), passing -1 will list all
of them.

Need to figure out full listing/pagination of blogs as well, that's the
final must-have feature for this tool.
Update tmpl.nim to reflect dropping config.cfg

Since we're using templates we don't need to put these things in via
variables read from a config.cfg file, people can just change their
Added a modification time check for performance

Once you get a number of pages/posts together the performance starts to
suffer somewhat (~7s for 40 rendered pages on my machine), and the bulk
of that time is spent inside the markdown() function call which is in
one of the dependencies for this project.

So for the time being we get around this by checking modification times
of the markdown files versus the existing html files and only rebuild
them if the markdown was modified later than the html, or if the html
doesn't exist obviously.

That saves a whole bunch of time as it only takes about 0.2-0.3s for a
single markdown file to render.
Add scdoc man-page file for docs

Also make a nimble task for running scdoc over the man page
Fixed a bug introduced during refactoring

I didn't properly render blog posts as actual pages so they didn't get
any CSS styling or anything, that's fixed now though.
Remove cleanCmd and config.cfg code

I realised I don't really need/use a clean command, my OS has tools for
taking care of that so I don't need to build it into dtt.

Also cleaning out remnants of config.cfg code since I don't use it
Added a findBaseDir proc to search for a dtt dir

We don't use the config.cfg file anymore so I needed a better way to
find a dtt directory, now it will scan for a content directory upwards
and error out if it can't find it.

Should make it check for content + template to be really sure it won't
conk out.
Remove unused code and slimline blog management

Now everything runs much smoother and the code is easier to follow
I think. There's still a few rough edges here and there but it's much
better now to build on this.
Optimize buildCmd to use fewer loops

This is a big change that optimizes away the multiple loops to scan for
blog posts, find links to pages, and render pages out. Now it does one
major loop collecting everything then one loop to render and write pages
out that goes much faster since it's doing fewer things.

Next up is refactoring the code to reduce duplication and complexity.
Fix the recursive config.cfg bug

Now you can be in any directory inside the dtt directory and run `dtt
build` and it will work as expected as long as you have a config.cfg
file somewhere.
Split all non-command procs out into utils.nim

This is the first stage of refactoring, just getting it out into a
separate file where it's easier to get an overview.
Tweak templates for blog output
Fix a11y issue with nav links
Add blank favicon
Add recursive searching for config.cfg

Now it will let you build your site anywhere inside your site's folder
structure and give you a nicer error message if you run the build
command in the wrong folder (no config.cfg found).

It would also let you share a config.cfg between two sites by placing it
in a parent directory to the two sites:


Not sure why you'd want to do that, but the tool will let you anyway :)
Find URL targets for blog posts

This way the blog title can link to the actual blog html page so you can
open just one post and read only that.