More CFile usage, few style fixes

Use more CFile instead of FILE.
Don't allocate (big) buffers on stack (that memory cannot be freed)
Fix an (unlikely) filehandle leak in frontend.cpp
rcinput et al: Implement hotplugging input devices

Add an interface to add/remove devices. Add a netlink socket to
listen for incoming hotplug events and (un)register input
devices.

Now you can (un)plug a keyboard while E2 is running.
 fix typo
eDVBUsbAdapter: fallback to dvb_frontend_info name

When /sys/class/dvb/dvb%d.frontend0/device/[product,manufacturer]
are missing, use dvb_frontend_info.name instead.
When dvb_frontend_info.name does not contain a usable name,
fallback to a hardcoded default.
eDVBResourceManager: add 'system' parameter in canAllocateChannel

Callers should never try to guess the dvb system based on the return value.
eStaticServiceDVBBouquetInformation::isPlayable was doing just that,
which caused unpredictable behaviour in the alternative services
priority.
dvb: Log in decimals, not hex. Use 1GB spans.

Log offsets and PTS in decimal, so that humans can understand them.
Report 1GB spans instead of 10MB, so that the calculation of spans
doesn't need to be repeated as often.
dvb.cpp: Refactor getNextSourceSpan

Get rid of code duplication by introducing diff_upto().
tstools always returns aligned offsets, so there's no need to align
them again. Otherwise, the more sensible thing to do would be to
fix tstools, instead of sprinkling the code with align() calls.
Updates for show single frame.

- allow h264 still images to be shown (based on showiframe patch from
  Erik slagter)
- vusolo2 (and probably dus2 too) did not properly show single
  iframes in enigma2 with drivers from before 2013. This was very
  noticable when in radio mode.

Conflicts:
	lib/dvb/decoder.cpp
fix typo in decoder.cpp

Thanks IMS
Fastscan: made transponder parameters configurable in python
eDVBFrontend::readFrontendData: only get SNR/AGC/BER when we have a lock

avoids a few ioctl's while we're tuning
pmt: always restart m_PAT/m_PMT when frontend state changes to ok

Even if we have already allocated a demux, it could be that
m_PAT / m_PMT have timed out (or returned invalid data) on
the previous attempt.
When that happened, we would not restart them when the
frontend lost and re-gained it's lock, because we already
allocated a demux.

This situation might occur with a rotor setup for instance,
where the frontend gets a lock before the positioner has
reached the correct orbital position.
(as might happen when there is no current measurement, or
current measurement is not reliable)
As a result, no channel would be started, and no retries
would be attempted.
scan.cpp: Add missing fcntl.h include

Some compilers might complain like this:
error: 'O_RDONLY' was not declared in this scope
subtitle: fix pts LSB, and slightly optimize extract_pts
subtitle: fix closing brackets

caused by 3b24f0d476f16733823852e3778360a8276d9b59
subtitle: undo HBO hack

The HBO hack, which was introduced in
8ae90fb361092e8bc95a269dfacdc695292e574b
breaks other providers, and it seems no longer
needed for HBO.

As suggested by ims.
typo in NationalOptionSubsets for czech
tstools: Correctly and efficiently calculate recording length

A recording with dicontinuities, such as when you've cut out commercials
or when there were big dropouts during recording, did not account for those
when the length was requested.

To fix this, take the discontinuities into account, which are calculated from
the .ap file. Use the "fixupPTS" function to correctly estimate the length.

Improve efficiency: Keep the calculated length as a member, because it is being
requested many times per second while playing.
tstools: force m_pts_length to be recalculated when m_pts_begin is set

m_pts_length can be correctly calculated (by calcEnd) only when
m_pts_begin is known, so calcBegin should have succeeded before
calcEnd is called.
Under certain circumstances, calcEnd could succeed before calcBegin,
leaving m_pts_length at an illegal value.
In that case, eDVBTSTools::calcLen might return an invalid length.

To avoid this, make sure the end value is invalidated, whenever
the begin value is set.
That ensures that begin and end are always calculated in the right
order, and m_pts_length will always be correct when m_begin_valid
and m_end_valid are both set.

thanks to betacentauri for finding this issue
tstools: calcEnd corrections

-use temporary variables for getLastFrame and fixupPTS,
current values might be invalidated when the function
fails, in which case we should stick to our previous
values

-m_offset_end should not change without m_pts_end, they
are always used as a pair

issues reported by betacentauri