Lock is released when cronlock exits

I don't understand how this tool is working. Here's an example:

```
$ (./cronlock && echo Starting A && sleep 10 && echo Finished A) &
[1] 8117
Cronlock: locked [lock.cronlock]. Returning success.
Starting A

$ (./cronlock && echo Starting B && sleep 10 && echo Finished B) &
[2] 8140
Cronlock: locked [lock.cronlock]. Returning success.
Starting B

$ (./cronlock && echo Starting C && sleep 10 && echo Finished C) &
[3] 8157
Cronlock: locked [lock.cronlock]. Returning success.
Starting C

Finished A
Finished B
Finished C

[1] Done ( ./cronlock && echo Starting A && sleep 10 && echo Finished A )
[2]- Done ( ./cronlock && echo Starting B && sleep 10 && echo Finished B )
[3]+ Done ( ./cronlock && echo Starting C && sleep 10 && echo Finished C )
```

I'd expect the second and third commands to fail.

The reason for the issue is that after the lock is acquired, the `cronlock` process is done and all its locks are released (along with file descriptors, sockets, etc.).

A solution would be to accept the command-line to run as an argument, and to run it in a sub-process. During that sub-process lifetime the lock is still taken because the `cronlock` process is still running. This is exactly the approach taken by [lockrun](http://www.unixwiz.net/tools/lockrun.html) or Linux's [flock](http://linux.die.net/man/1/flock).

Start at cronlock's command-line entry point and trace how it acquires and releases the lock. The change is complete when cronlock can run the supplied command while retaining the lock for that command's lifetime, and concurrent invocations fail as shown in the example.

Written by the indexing model from the issue text.