The files it downloads are not versioned, and they could
change any time. GRUB has no way to deterministically grab
these.

I've removed GRUB's local for grabbing these, instead
mirroring them myself and checking hashes; no hashes seem
to have been provided by the upstream at Translation Project,
so I just used the hashes I had on the files it had, when
I downloaded them.

From now on, I can just re-download these and re-calculate
the hashes as desired, over time, when updating GRUB revisions.

Signed-off-by: Leah Rowe <leah@libreboot.org>

This reverts commit 1e07c4eb02da5c51d5278583b2a3e2de551f2a62.

this time to source hut.

for some reason, *grub* is slow no matter what repo
provider i host it on??

i tested srht just now, and it seems ok. let's use that.

i'm *paying* for this sourcehut account, so it better be
good!

Signed-off-by: Leah Rowe <leah@libreboot.org>

We are calling xbmkget in the same way, whether it's
a subfile or subrepo.

Rename these variables to subcurl and subgit, so that we
can call xbmkget unconditionally.

Signed-off-by: Leah Rowe <leah@libreboot.org>

the gnu.org mirror is always slow for some reason, but only
for gnulib. it may only be for me, because routing in other
countries/networks may differ.

when i'm freshly cloning lbmk modules, gnulib is always really
slow, like 300KB/s (bytes, not bits)

i have 1gbps internet and wish to not have 2005-era speeds,
thank you kindly!

Signed-off-by: Leah Rowe <leah@libreboot.org>

Signed-off-by: Leah Rowe <leah@libreboot.org>

remove nvme support from the "default" grub tree

now there are three trees:

* default: no xhci or nvme patches
* nvme: contains nvme support
* xhci: contains xhci and nvme support

this is in case a bug like lbmk issue #216 ever occurs
again, as referenced before during lbmk audit 5

there is no indication that the nvme patch causes any
issues, but after previous experience i want to be sure

Signed-off-by: Leah Rowe <leah@libreboot.org>