feat: configure initial provider load concurrency

[xYx-c]

Summary

Make initial provider loading concurrency configurable with the new top-level YAML option:

provider-load-concurrency: 1

When omitted or set to a non-positive value, Mihomo preserves the current architecture-specific default unchanged:

• amd64 / arm64 / 386: unlimited
• other supported architectures: 5
• mips / mipsle: 1

The configured value applies to both proxy-providers and rule-providers during initial configuration loading.

Motivation

On memory-constrained routers, many large rule-providers loaded concurrently can create a large transient allocation peak. A 512 MiB ARM64 OpenWrt device with approximately 300k domain rules previously failed intermittently during startup under the unlimited ARM64 default. Using a local one-line serial cap (1) made repeated restart and stop/start tests reliable while preserving the YAML rules and routing behavior.

A config option avoids requiring a private rebuilt Core for this device class, while retaining the current parallel behavior by default for users who value startup speed.

Semantics

# Omitted / 0 / negative: use the existing architecture default.
provider-load-concurrency: 0

# Strictly serial initial provider loading.
provider-load-concurrency: 1

# Bounded parallel loading.
provider-load-concurrency: 2

Validation

gofmt -w config/config.go hub/executor/executor.go hub/executor/provider_load_concurrency_test.go
git diff --check
go test ./hub/executor -run TestProviderLoadConcurrency -count=1 -v
go test . ./hub/executor ./ntp/ntp
GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build -tags with_gvisor ...

All checks passed. The cross-compiled output was verified as a statically linked Linux ARM64 ELF.