[build] Build liburing statically; order Folly after it

[chuandew]

What changed

• build and install liburing with ENABLE_SHARED=0
• make Folly explicitly depend on the liburing ExternalProject

Why

Folly auto-detected Eureka's shared liburing.so and exported it through Folly::folly_deps. DingoFS consumers then acquired a runtime dependency on liburing.so.2, while the runtime image only carries the statically linked dependency set.

The explicit dependency also prevents Folly configuration from racing liburing installation or falling back to the system library.

Validation

• clean RelWithDebInfo build of dingo-eureka
• isolated install contains liburing.a and liburing-ffi.a, with no liburing shared object
• Folly::folly_deps exports /tmp/dingo-eureka-build/lib/liburing.a
• clean builds of dingo-sdk and dingo-store
• clean build of DingoFS PR #1109 (ecf98eb4086ca6c2473942e2581aee3205deff5b)
• all 10 produced DingoFS ELF executables have no DT_NEEDED entry for liburing.so and no unresolved runtime libraries
• dingo-mds-client --help reaches application startup without a loader error