license header in .gitattributes

made help look better on mobile

Since the help is mainly intended to be browsed on a desktop/laptop
computer on which one is running the software -- and the software
doesn't work on mobile devices -- this is not very important. But
it's no harm.

Before this, some mobile devices would display the text at full
size, which was okay but a bit bigger that necessary given the
distance at which readers tend to hold their mobile devices (and
given the ability to zoom easily while still seeing the full width,
when margins are visble). But other mobile devices would, at least
going by the results in Firefox's Responsive Design Mode, show the
text very small.

Now the text should consistenetlyappear moderately smaller than on
a regular browser, but still big enough.

make fill steps invalidate whole canvas again

This is a manual revert of 34c3289.

When concurrent fills cover most of the canvas and also interact
heavily, starting at ~30 fills and almost always by ~50 fills, huge
lag spikes would happen, and the canvas would be mostly
nonresponsive and largely frozen until the number went down.

I didn't notice this for a while because I didn't test that case.
The bug occurred, repeatedly, when a friend tried out the program.

The problem, apparently, is that invalidating a huge number of
1-pixel rectangles is much less effiicent than invalidating the
whole canvas.

This makes sense, since repeated invalidations of the same region
are likely bunched together efficiently by whatever algorithm
Windows uses to implement the default WM_PAINT behavior.

See the commit message of the "reverted" commit for more thoughts
on this ill-advised premature optimization. I had thought it would
likely need to be reverted at the time... but then forgot about it.

moved help and tips files into a doc folder

unified help/tips color boxes (fixes tips alignment regression)

Also, used times signs instead of lower-cases "x"es for speed
multipliers, and requested tabular numbers (though I don't believe
this makes any difference for Segoe UI, the first-requested font in
tips and the one that should always appear when running the app).

fixed infobar height regression

The height of infoBar was too high (100).

added random per-fill neighbor enumeration strategy