scalelite_prune_recordings.sh will never be executed if put under /etc/cron.daily (as suggested)

[Ithanil]

Describe the bug

The file bigbluebutton/scalelite_prune_recordings.sh is supposed to be downloaded and put into /etc/cron.daily without further modifications. But according to the naming rules of cron, it will not be executed due to containing a dot in the filename. Quote from man cron:

       Support for /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly is provided in Debian through the default setting of the  /etc/crontab  file  (see
       the  system-wide  example  in  crontab(5)).   The default system-wide crontab contains four tasks: run every hour, every day, every week and every month.  Each of these
       tasks will execute run-parts providing each one of the directories as an argument.  These tasks are disabled if anacron is installed (except for  the  hourly  task)  to
       prevent conflicts between both daemons.

       As described above, the files under these directories have to pass some sanity checks including the following: be executable, be owned by root, not be writable by group
       or other and, if symlinks, point to files owned by root.  Additionally, the file names must conform to the filename requirements of run-parts:  they  must  be  entirely
       made up of letters, digits and can only contain the special signs underscores ('_') and hyphens ('-').  Any file that does not conform to these requirements will not be
       executed by run-parts.  For example, any file containing dots will be ignored.  This is done to prevent cron from running any of the files that are left by  the  Debian
       package management system when handling files in /etc/cron.d/ as configuration files (i.e. files ending in .dpkg-dist, .dpkg-orig, .dpkg-old, and .dpkg-new).

So, the file needs to be renamed to e.g. scalelite_prune_recordings and also made executable to do what it is supposed to do. This should at least be reflected in the comments/documentation, but obviously it would be better to rename the file in the repo as well. Only consideration would be that it could break some build processes relying on an URL to the SL repo.

[Ithanil]

Fixed with #1055