Externals Update and CMake Fixes, master branch (2020.12.01.)

Updated all projects to atlasexternals-2.0.91. The changes wrt. atlasexternals-2.0.89 are the following (atlasexternals@2.0.89...2.0.91):

• The AtlasLCG modules now set up imported targets for the libraries and executables that they found;
• Re-designed how ROOT and its dependencies would be built for AnalysisBaseExternals;
• Introduced Findpprof.cmake to AtlasLCG (thanks to @amete);
• Made FindTBB.cmake set up its imported targets correctly, and updated FindGaudi.cmake to use AtlasLCG's FindTBB.cmake directly.

The ROOT build update was necessary to fix the problem discussed in ATLINFR-3852, which showed up very often recently in AnalysisBaseExternals CI builds.

While testing my changes for atlasexternals-2.0.91 I ran into two independent issues in my local build as well:

• I finally figured out why Control/RootUtils was giving us such a hard time. As it turns out, CMake will not execute FindROOT.cmake twice just because you call find_package(ROOT...) twice in the same file. You have to force it to do so, by unsetting ROOT_FOUND between the two calls.
• Purely by chance I discovered a very scary setup in PhysicsAnalysis/TauID/TauAnalysisTools. The dictionary generation of that package failed in my local test because:
  • TauAnalysisTools/TauEfficiencyCorrectionsTool.h had a big mistake in it (on top of that sort of code just being very scary to start with);
  • By chance my build directory already had the include directory of PileupReweighting linked into the "include directory" of my build directory, while the include directory of AsgAnalysisInterfaces was not soft-linked in there yet. Revealing this code error. (The dictionary generator "sees" headers from the ROOT_INCLUDE_PATH environment variable as well. Which apparently introduces a race condition in our build that I was just not aware of so far...)

I didn't do any bigger cleanup in TauAnalysisTools since it seems it still needs to be updated with the code from 21.2. (Right...? @lheinric, @krumnack)

Note that this MR itself would not necessarily need full-build. But the changes in the build of ROOT would very likely break the build of AnalysisBaseExternals for the next CI job (still using the old configuration) on the same build node.