Allow different but equivalent time zone ID's

[sphery <mtdean@…>]

The attached patch allows different but equivalent time zone ID's. Since many zoneinfo rules files have differently-named copies within the database (which should, in fact, be hard-linked files), it is theoretically possible that 2 myth systems may be running with the same time zone configuration, but the identified zone ID names may differ. This patch simply adds an extra comparison when zone ID names differ to see if the 2 zone ID names are equivalent by comparing the 2 zoneinfo rules files.

The patch adds a new helper function compare_zone_IDs() to replace the QString zone ID comparison and factors out the file-comparison code from findZoneinfoFile() into a helper function, compare_zone_files(), so it can be used by both findZoneinfoFile() and the compare_zone_IDs().

[stuartm]

(In [18956]) Fix two potential segfaults in mythui ported screens, both caused by failing to check the validity of a button list item pointer before dereferencing. Cleaned up a little too. Closes #5872 and #5873

[stuartm]

Meant to close #5871

[sphery]

(In [21337]) Allow different but equivalent time zone ID's.

This allows Myth applications to run even if the detected time zone ID (name) differs from the one detected on the master backend, but only if the zones are actually using identical definitions. Therefore, using a combination of US/Eastern with America/New_York or America/Los_Angeles with US/Pacific or Europe/London? with Europe/Belfast? for the 2 processes would work.

Different time zones--even if the current time is identical in those differing time zones--are still not allowed as Myth needs to ensure that all local times used by the 2 processes are identical in the past, present, and future. Therefore, using America/New_York with EST5EDT or US/Pacific with PST8PDT would not work as those combinations specify zones whose times differ in various periods in the past.

Closes #5872