LKUtils, InputEvents: close the handles returned from CreateProcess()

MSDN says: "Handles in PROCESS_INFORMATION must be closed with
CloseHandle when they are no longer needed."

Fix for a memory leak.
LKInstall: fix memory leak
CommandLine: remove unused parameter
lk8000.rc: remove obsolete ACCELERATORS section
wcecompat/ts_string: add missing stdlib.h include

For malloc().
Common/Data/Bitmaps: shrink brush pattern to 8x8

GDI is optimised for 8x8 patterns.  This reduces the time needed for
DrawAirSpace() by 40% on a Dell Axim x51v.  Other graphics
chips/drivers may result in different speedups, however it is safe to
say that 8x8 is the best bitmap size for patterns.
Revert "Bug fix in task start/finish lines"

This reverts commit f3fe24fbed27aa6864b3ac7710c696d20591b4d1.  This
commit is obscure, bloats the code, adds CPU overhead, and is still
wrong.
Calc/TaskUtils: fix rounding error in sector angle calculation

A great circle is the shortest path on earth's surface from one point
to another.  A big problem with great circles is that while flying on
one, your bearing will change over time.

Simple example: fly from Canada north (360 degrees) until you pass the
north pole, continue flying straight until you hit Russia.  You are
now heading south (180 degrees), even though you have not turned, and
you are still flying on the very same great circle in the same
direction.

The problem that is addressed by this patch is not so drastic, however
it must be addressed or LK8000 task calculations are wrong.  I fixed
the same bug in XCSoar yesterday, and LK8000 being derived from XCSoar
has been sharing the same bug for quite a few years.

The calculation of symmetric sectors was using the wrong reference,
and therefore was using the wrong angle!

Imagine a task consisting of just one start point and a finish line.
LK8000 determines the orientation of the finish line by calculating
the angle from start to finish .... WRONG!  Wrong because it looks at
the task from the eyes of the start point, but we really want to
calculate the finish line.  Therefore, the reference must the the
finish line.

The error is small (sometimes 0.1% or less for common tasks), but
still it is significant if you miss the finish line by a few hundred
meters.

Thanks to Peter Scholz for noticing the problem and providing sample
data (http://bugs.xcsoar.org/ticket/2209).