Fetch pinned darling-swift LFS objects from GitHub, not the dead host

The pinned src/external/swift/.lfsconfig points lfs.url at the retired
git-lfs.darlinghq.org, so a fresh `git submodule update --init --recursive`
blocks with no output right after src/external/sqlite is checked out: swift is
the next submodule in sorted order and its checkout waits on that host.

Override lfs.url to GitHub's endpoint, which still serves the objects (verified
44 objects / 16 MB, real Mach-O dylibs), and print explicit submodule progress so
the last completed submodule is not mistaken for the stalled one.

scripts/prepare.py

@@ -13,7 +13,16 @@ if not (source/'.git').exists():
     source.parent.mkdir(parents=True,exist_ok=True)
     run(['git','clone',manifest['upstream'],str(source)])
     run(['git','-C',str(source),'checkout','--detach',manifest['revision']])
-    run(['git','-C',str(source),'submodule','update','--init','--recursive'])
+    # Recursive initialization can spend a long time fetching nested repos (and
+    # Git LFS assets). Explicit progress keeps the last completed submodule
+    # from looking like the operation that is currently stuck. The pinned
+    # darling-swift .lfsconfig points at the retired git-lfs.darlinghq.org, so
+    # fetch that submodule's LFS objects from GitHub, which still serves them;
+    # otherwise the checkout blocks on the dead host right after sqlite.
+    print('Initializing Darling submodules (large repositories/LFS assets may take a while)...',flush=True)
+    run(['git','-C',str(source),'-c','lfs.url=https://github.com/darlinghq/darling-swift.git/info/lfs',
+         'submodule','update','--init','--recursive','--progress'])
+    print('Darling submodules initialized.',flush=True)
 # Never reset someone else's checkout to make a patch apply.
 for component in manifest['components']:
     repo=source/component['path']