Removed memory allocation when reading MIDI data.
Move reset() out of the audio thread.
It doesn't need to be there, and could possibly starve other threads
since the audio thread is realtime.
Added missing header define.
Removed unused function.
It will conflict with later patches.
Removed pointless calls to gettimeofday.
They are not used anywhere in the function.
Switched to using shared memory for process communication.
The reason this was done is to improve the real time performance of
dssi-vst. The old communication method used in the plugin was pipes,
which are not guaranteed to have a bounded execution time, safe for a
real time environment. Therefore, in this patch, we switch to using
shared memory with a ring buffer as the data stream and semaphores
for synchronization.

Pros:
- The plugin has no extra latency anymore, since the semaphores will
properly wait for data to be processed in each call to run().
- If there are xruns, they will be filled with silence and properly
reported to jack. Previously, jack would not get notified of the
xrun, and there would be a terrible noise (which was because the
old buffer data was not cleared and would be repeated several times
over).
- We can enable the LADSPA_PROPERTY_HARD_RT_CAPABLE flag, since the
dssi-vst layer no longer introduces any function calls with
unbounded execution time. It is still possible for a plugin to be
badly coded and cause xruns, but then the problem is in the VST
plugin and not in dssi-vst.

Cons:
- It is now harder to detect whether the remote side has shut down,
since the semaphores will not detect this like a pipe does.
- The ring buffer has a certain size, which could theoretically
overflow. However, it is very unlikely, unless you send a huge
amount of MIDI data at once.

Some comments about things that were done in the patch:
- Linking to a new library, -lrt, was necessary because we need to
call clock_gettime when using semaphores.
- "extern" was removed from functions because... well, I didn't see
why they needed to be there, and they caused some problems with the
templates.
- The template functions were introduced mainly to save time, not
having to reimplement the read/write functions for all the
datatypes.
Fixed sporadic xrun bug in shared memory code.
This one was hard to track down. The symptom was that a few times,
sometimes several hours apart, the native plugin code would take much
longer than normal to complete, causing xruns for the plugin host.

It turns out that since the shared memory being used is backed by a
file, the Linux kernel likes to flush the contents in memory back to
the file occasionally. While it does this *it locks the memory
pages*, meaning that the plugin, which tries to write to the memory,
is suspended until the file write is complete.

Of course, waiting for file I/O inside the realtime code is
unacceptable, so we need shared memory that does not flush to disk.
The fix was to switch to POSIX shared memory objects, using
shm_open(), instead of normal file open().

Also fixed a trivial bug where the shared memory was opened twice
(mkstemp already opens the file, but we still opened it again
afterwards).
Made the standalone vsthost respond properly to MIDI program changes.
The MIDI data for program change should not be passed to the plugin
(at least not as per the DSSI spec). Instead, translate them into a
function call to set the current program in the synth.
Switched to using vfork().
It causes less xruns when launching a new plugin instance, even if
the launch happens from a non-real time thread. Presumably, fork()
blocks all threads in the parent task while the process is cloned,
while vfork() doesn't make a copy and therefore doesn't block.
Properly handle when plugin has no maker, param or program name
This is triggered when a plugin crashes while initializing,
thus the plugin information is not filled properly and currupts the dssi-vst cache