WIP: Support additional forges

[mmatous]

Hi, this PR contains support for additional SW forges. Project source link in header, link shortening, and edit button are separated by commit.

I had some trouble with SVG assets due to having little experience with CSS or Webpack. How should I bundle them? I couldn't figure out the correct Webpack config, so they're inline for now.

Should I grayscale the icon link in header considering the note about not styling social media icons due to a11y in _icon-links.css?

pydata-sphinx-theme/src/pydata_sphinx_theme/assets/styles/components/_icon-links.scss

Line 47 in 3e74810

/* We no longer color the social media icons in their brand colors (makes a11y harder)

How should I handle Codeberg shortlink icon and dark/light mode? The inlined one changes colors in the exact oposite way than I'd like (dark blue on dark) and its other version works fine on dark but disappears on light theme. I tried two separate defs in _icons.scss inside html[data-theme="dark|light"] (mentioned in https://pydata-sphinx-theme.readthedocs.io/en/latest/user_guide/styling.html#color-variables) but that didn't work.

I also noticed a function being called unnecessarily and fixed that in a separate and a bit offtopic commit. I can send that one in a different PR, if you'd like.

Requested in #2201

[gabalafou]

Hey, heads up, we're refactoring the way that we shorten URLs in #2068

[mmatous]

Should I drop the corresponding commit and make a separate PR for shortening these forges later?

[drammock]

Should I drop the corresponding commit and make a separate PR for shortening these forges later?

Yeah I think separating the logo etc from the link shortening will make it easier to review/merge this quickly, and then do a separate PR for link shortening after #2068 lands

[mmatous]

dropped the shortening, rebased on current main HEAD

[Carreau]

I'm marking as good to have, but I don't think we should inline svg like that it's impossible to review, and with some of the recent-ish xz-backdoor I think we should be worried about that kind of blobs; even if here SVG is ok-ish.

[drammock]

I'm marking as good to have, but I don't think we should inline svg like that it's impossible to review, and with some of the recent-ish xz-backdoor I think we should be worried about that kind of blobs; even if here SVG is ok-ish.

FYI, FontAwesome 7.2 (just released) has an icon for forgejo (but not Gitea). @Carreau would you be ok with putting the SVG data here instead?

pydata-sphinx-theme/docs/_static/custom-icons.js

Line 1 in 0634533

FontAwesome.library.add(

[Carreau]

I can be convinced of either; SVG are relatively simple in those case so I can be convinced to keep them inline. I think it also sort-of make sens to have them at separate file with build step to at least be able to see them in typical case when browsing the repository, either locally on the web.