Update Font Awesome Free from 6.4.2 to 7.2.0

[stweil]

This fixes some deprecation warnings with newer releases of Sass.

Note that the new release no longer uses $fa-font-path. Therefore the expected font path is now provided by a symbolic link.

[demiankatz]

@stweil, a few thoughts/comments:

1.) The code needs to be compiled, and the updated compiled.css files need to be committed. At present, in this branch, the SCSS has been updated but the compiled CSS output still contains FA6.

2.) I'm concerned about the reliance on symbolic links; I think this could cause problems with cross-platform compatibility and packaging workflows. Is it possible that we can achieve the same effect with pure Apache configuration (e.g. just alias /webfonts to the appropriate subdirectory)? Or better still, is there some other way to do this without symlinking OR Apache hacks? For example, is it possible that there is no longer a reason to use the SCSS version of FontAwesome, if they're reducing the number of variables anyway? Would using a pre-built CSS version allow us to reorganize the files in a way that won't break font loading?

[crhallberg]

Instead of symbolic links, would it be a good time to move Font Awesome to npm and copyDependencies.js? Then we can put Font Awesome exactly where we like.

[demiankatz]

@crhallberg, I agree that we should use copyDependencies if we're not already. But the other wrinkle here is that I think the FontAwesome SCSS now has a hard-coded relative path to the webfonts (instead of the previous way where you could set a variable to customize the path), and when everything compiles into compiled.css, that ends up pointing at a URL that doesn't work. That's why I'm wondering if we should consider abandoning the SCSS version, in case a prebuilt version gives us a more stable output. (It looks like you did use the prebuilt CSS version in #4031, so that seems to indicate that it is a workable approach).

[demiankatz]

It occurs to me that npm run check:scss is supposed to detect the fact that compiled.css has not been committed here and break the build -- but that has not happened. Maybe something is wrong with that tooling. I don't have time to investigate at this moment, but I'll try to remember to circle back to it if nobody else gets there first.