Font Awesome icons are broken when the icon class is set on .btn or a.button elements

Regression introduced XWIKI-15026.
Note this is not the same problem as XWIKI-24073 (accepted as wontfix)

Reproduction steps

On any 18.x page, in the browser console:

['span','a','button'].forEach(tag => ['fa fa-download', 'fa fa-download btn', 'fa fa-download button']
  .forEach(cls => {
    const e = document.createElement(tag);
    e.className = cls;
    document.body.appendChild(e);
    console.log(tag + ' | ' + cls + ' | font-weight=' + getComputedStyle(e, '::before').fontWeight);
    e.remove();
  }));

Or, with an extension installed that uses the Font Awesome 4 idiom of putting the icon class directly on the button (reproduced with the view-file macro of the xwiki-pro-macros-ui extension, version 1.32.0, which builds its modal download button as <a class="fa fa-download button button-primary">Home - XWiki.pdf</a>):

• Attach a PDF to a page and insert {{view-file}} for it
• Click the PDF preview thumbnail
• Look at the download button in the top-left corner of the modal

Expected result

The icon renders (as it does on 17.10.x with Font Awesome 4.7.0), and the button's background wraps both the icon and its text label.

Actual result

• The icon is a "missing glyph" box.
• The label spills out of the button's background, because width: var(--fa-width, 1.25em) clamps the element to ~26px while the label needs ~113px.

Measured on the same page, same extension, two instances:

Setting font-weight: 900 and --fa-width: auto on the element restores the 17.10.12 rendering exactly.

Notes

xwiki-platform itself is not affected: it never puts the icon class on the button element, it always nests the icon in a child, e.g. <a class="btn btn-default"><span class="fa fa-download"></span> Label</a>. A grep over the
templates, skins and resources of the 18.4.4 distribution finds zero elements carrying both an fa fa- class and btn/button. So this only shows up in extensions written against Font Awesome 4, where putting fa fa- on the button itself was a valid and common idiom – it is a backward compatibility break for those extensions rather than a visible platform bug.

Affected combinations

Verified on 18.4.4 – computed ::before font-weight: