[pvr.tvh] store the capabilities sent by the server
[pvr.tvh] don't fool XBMC into thinking we can timeshift if in fact we cannot
[pvr.tvh] store the timeshift status so the data can eventually be used
[pvr.tvh] implement GetPlayingTime()

What it means is we convert tvheadend's notion of "seconds shifted" to an
absolute timestamp.

This fixes two issues. The first one is that if you pause a live stream at e.g.
10:00 program time (ie. 10 minutes after it has started), wait for 30 seconds,
unpause and then rewind 30 seconds, XBMC would display the current time as
11:00 when in fact it should be 10:00 again (since we rewinded the buffer to
the beginning).

The other issue is more of a new feature. Now when you pause a live stream
long enough XBMC will display the shifted position along with the live position
in the seek bar, so you know roughly where in the shift you are.
[pvr.tvh] don't confuse the user by saying we failed to get a response

In fact we got a response but it was invalid or had no meaning (I'm not
totally sure what a time of -1 means)
[pvr.tvh] populate the event icon if there is one

It's not currently used by the default skin, but still
[pvr.tvh] trigger EPG updates asynchronously as they arrive
[pvr.tvh] remove unused global variables
[pvr.tvh] use m_CurStatus when appropriate and avoid changing it
unnecessarily
[pvr.tvh] add missing delete call
Merge remote-tracking branch 'origin/pr/18'
Merge remote-tracking branch 'origin/pr/19'
Merge remote-tracking branch 'origin/pr/20'
Merge remote-tracking branch 'origin/pr/21'
[pvr.tvh] - some ammendments to PR #21
Merge remote-tracking branch 'origin/pr/22'
[pvr.tvh] Addressing overflow causing timeshift to jump to begining of stream
[pvr.tvh] Setting the group name before passing to XBMC
[pvr.tvh] - bump version number to 0.5.0
[pvr.tvh] - fix deadlock bug caused by adding async EPG triggers

Strictly I think this could have been possible for other things, but it was
probably less likely. But basically the XBMC update triggers require a lock
that can be held while requesting data from pvr.tvh, which in turn requires
a lock held by the thread trying to trigger the update. Thus creating a
deadlock.

To remove this possibility all XBMC trigger routines are called once the lock
has been released (they're queued up by the processing messages).