feat: support multiple blacklist providers

[nikooo777]

Summary

• Add blacklist_providers config key (JSON array) to configure multiple blacklist sources
• Each provider is fetched independently with try/catch isolation so one failing provider doesn't break the rest
• Blacklists from all providers are merged into a single ETS cache (union of all IDs)
• Backward compatible: singular blacklist_provider key still works

Config example

{
  "blacklist_providers": [
    "/~relay@1.0/call?relay-method=GET&relay-path=https://provider-a.example.com/blacklist",
    "/~relay@1.0/call?relay-method=GET&relay-path=https://provider-b.example.com/blacklist"
  ],
  "on": {
    "request": { "device": "blacklist@1.0" }
  }
}

Note: blacklist@1.0 must be in the on/request hook chain to intercept requests. It is not in the default hook chain (hb_opts.erl), so it must be explicitly configured. This is also true for the existing singular blacklist_provider key.

Test plan

• multiple_providers_test — two separate blacklists, IDs from both are blocked
• backward_compat_test — singular key still works
• provider_failure_resilience_test — bad provider doesn't break good ones
• plural_numbered_message_test — numbered message map (structured config) works
• Manual integration test with config.json + curl against running node

[samcamwilliams]

Looks good but no need for the backwards compat here. Clanker has over indexed on that, so the 'still works' test can go, much of the comment change, as well as plural_numbered_message_test, etc.