SoftCSA OpenATV

Adds a new "Aggressive" level to config.softcsa.decoderRelease that
applies two workarounds for HW-descrambler driver bugs observed on
dm52x + dm9x0 (broadcom STB chip on this generation does not
implement the DVB CA slot release reliably):

1. HW-descrambler slot reset on channel change
When leaving an encrypted, HW-descrambled service, the driver
leaves the HW slot programmed with the previously used PIDs and
CWs. oscam itself behaves correctly - on channel change it sends
CA_SET_PID(<pid>, -1) for every stream of the old service, and
once it detects CSA-ALT on the new service it stops touching the
slot at all.
On a working driver the leftover slot would just pass scrambled
data through. On dm52x + dm9x0 the slot keeps descrambling with
the old CWs - whichever PID happens to match on the new service
arrives mangled. Symptoms: "broken startcode" floods on video,
dead audio tracks on SoftCSA services that land on the formerly
programmed PIDs.

In Aggressive mode, at cleanupSoftwareDescrambling() of an
outgoing HW-descrambled service (PMT carries CA descriptors AND
the CSA session was never activated), open ca<data_demux_id> in
parallel to oscam, disable each PMT stream PID with
CA_SET_PID(-1) and issue CA_RESET, then sleep 100ms for the
driver to settle. Adds ~100ms latency on every HW->* channel
switch; SoftCSA->X, FTA->X and FTA-only zaps are untouched.

2. Bypass the in-process CSA-ALT cache
eDVBCSASession caches its CSA-ALT verdict per service so that
subsequent visits to the same channel can skip the ECM section
reader and call setActive(true) immediately. This speeds up
channel switching, but on dm52x + dm9x0 it causes an audio race:
oscam (which also caches the service) delivers the first CW
almost instantly, the buffered CW gets replayed on activation,
and the SoftDecoder pipeline ends up starting on the audio
stream's first packets while the audio decoder is still warming
up - audio stays muted until the next uncached channel switch.
In Aggressive mode the cache-driven early activation in
startECMMonitor() is skipped, the regular ECM section reader
always runs, and activation happens on the actual ECM analysis
like before the cache existed. The cache is still populated and
used elsewhere (CWHandler pre-registration, skipping re-analysis
once an ECM was seen).