Extend mythutil to support sending multi-line events.

Use extra --event arguments to add more lines to the event.
Add duplicate checking and limited matching optimizations and other
scheduler related changes.

The three major changes are as follows.

Split the checks against the oldrecorded and recorded tables for
previous recordings away from the "place" phase of scheduling and call
it the "check" phase.  This makes it easier to report how much time is
spent doing this and leads to the next major change.

Drastically reduce the number of checks against the oldrecorded and
recorded tables for previous recordings.  Historically, this has been
the most significant contributor to long scheduler runs.  Not every
unnecessary check is eliminated, but the vast majority of them are.
Trying to remove the few remaining ones would probably take longer
than simply rechecking them.

Allow for checking a subset of the program table when new guide data
is available.  This is primarily aimed at EIT scanning where typically
only a few hours of guide data for specific channels is updated in an
orderly fashion.  Not rechecking the unchanged guide data greatly
reduces the amount of work the scheduler has to do.  Please note the
EIT scanner has not been updated yet to take advantage of this change.

The other changes are as follows.

Use more expressive reschedule requests.  This is primarily to support
the changes listed above.  It also makes it easier to understand why
reschedules occurred when reading the logs and might lead to the
elimination of unnecessary reschedules in the future.

  MATCH reschedule requests should be used when the guide data or a
  specific recording rule is changed.  The syntax is as follows.

  RESCHEDULE_RECORDINGS
  MATCH <recordid> <sourceid> <mplexid> <maxstarttime> <reason>

  maxstarttime should be in ISO format.  If recordid, sourceid or
  mplexid are non-zero or maxstarttime is a valid time, the scheduler
  will restrict itself to recording rules and guide data matching
  those parameters.  reason is purely for purposes of logging.

  CHECK reschedule requests should be used when the status of a
  specific episode is affected such as when "never record" or "allow
  re-record" are selected or a recording finishes or is deleted.  The
  syntax is as follows.

  RESCHEDULE_RECORDINGS
  CHECK <recstatus> <recordid> <findid> <reason>
  <title>
  <subtitle>
  <description>
  <programid>

  recordid should be the parent recordid, when applicable, otherwise,
  the normal recordid.  Setting programid to '**any**" and title to ""
  is a special case used to emulate an old reschedule request for
  recordid 0.  Setting programid to "**any**" and title to other than
  "" is another special case used when all entries for a title are
  deleted from oldrecorded.  recstatus and reason are purely for
  purposes of logging.

  PLACE reschedule request should be used in all other cases.  The
  syntax is as follows.

  RESCHEDULE_RECORDINGS
  PLACE <reason>

  reason is purely for purposes of logging.

Update the PHP and Python bindings to use the new reschedule requests.
Please note the bindings API has not changed to make full use of the
new requests.  I'm leaving it to the bindings maintainers to decide
how best to do that.

Clear record.duplicate when a recording is queued for deletion.  It
should have been this way all along and avoids a redundant reschedule
when the file is actually unlinked.

Lower the very detailed scheduler placement logging to LOG_DEBUG.
This makes VB_SCHEDULE/LOG_INFO more useful for less voluminous
purposes.

Add findid to the recordmatch table.  This avoids having to calculate
it in multiple places.

Tighten the window for rescheduling long running programs from "24
hours ago" to "~8 hours ago".

Avoid creating unnecessary RecordingInfo objects that are going to get
deleted later anyway.

Fixes #10533