Python 2 has been EOL since 2019, and isn't available in the Arch
repositories any more, so continuing to support it has become a major
hassle. The quick and dirty fix is to just build the DISIS cwiid library
without it, which seems to be the only part of the source which still
depends on Python 2 at build time.

On the Mac, we have to ship these along with libquicktime itself, and
define LIBQUICKTIME_PLUGIN_DIR in the environment so that libquicktime
finds them. Otherwise Gem's QT4L plugins won't be of much use.

This requires various changes throughout the build system. Moreover,
the Mac build now works with both Homebrew (in /usr/local/opt) and
MacPorts (/opt/local), but still prefers Homebrew if it is present.

We also adjusted the embed-MacOSX-dependencies.sh script to look for
libquicktime dependents in the right place ($PD_APP_CONTENTS/Plugins),
so that Gem's QT4 plugins will work using the Homebrew libquicktime
package. Alas, MacPorts doesn't have a working libquicktime package, so
the QT4 plugins are disabled there.

These are now proper errors instead of warnings, and the error message
on Windows is more informative as well, making it easier to detect and
diagnose such errors.

Backport from upstream:

https://github.com/pure-data/pure-data/commit/fee700b3
https://github.com/pure-data/pure-data/commit/af3894da

This adds all generated markdown and html docs for all target systems in
packages/gendoc to the self-contained distribution tarball (`make
dist`), so that no special tools like python-markdown are required to
build the package.

Built-in flag and live usage data are now combined into a single numeric
relevance score, with a boost factor determining the weight of the
former relative to the latter. This makes it easy to adjust the
relevance order. Currently we have the boost factor at 50, which means
that an external needs to have 51 uses before it gets preferred over a
built-in with no uses at all. Is this too large? Too small? Also, should
the fuse similarity score take precedence over relevance (currently it
doesn't)? At present nobody knows, so let's give it a try and listen to
user feedback to improve it.

If we find any LIBRARY meta data, record it in the completion index.
Currently this is only used to list built-ins ("internal" library) first
if sorting by relevance is enabled.

We now properly deal with argument completions scraped from the NAME
field, by checking for existing objects and argument completions, and
updating the object accordingly.