Add Developer SDKs and CLI section to main README

[pimfeltkamp]

Summary

• Add a new Developer SDKs and CLI section to the main README so the eight official SDKs (Node, Python, Go, Ruby, Rust, PHP, Dart, Swift) and the CLI are discoverable from the org's most-visible page.
• Each row links to the registry page, install command, and GitHub repo.
• Add a TOC entry for the new section.
• Update the Repository Structure block to also list CONTRIBUTING.md (which already exists on main but wasn't mentioned).
• Add a GitHub link to the Links section pointing at the org page.

Why

Anyone landing on cryptohopper-resources from search or from docs.cryptohopper.com should immediately see that there are official cross-language SDKs, with one-line install snippets for the language they care about. The existing API Access section described the API but didn't say "and here is how you call it" — this fills that gap.

Notes

• The new section references VERSIONING.md, docs/sdks.md, and docs/cli.md. Those files don't yet live on main — they are in PRs Add VERSIONING.md — SDK and CLI versioning policy #2, Add docs/sdks.md — public overview of the SDK suite #3, and Add docs/cli.md — public CLI reference #4. Once those land, the relative links resolve. Until then, the table itself stands on its own (registry + repo links work today).
• Did NOT preempt the additions in PR Add OpenAPI 3.1 spec for the Public API v1 #1 (openapi/) or PR Add VERSIONING.md — SDK and CLI versioning policy #2 (VERSIONING.md) inside the Repository Structure listing — each PR keeps its own structure update self-contained.

Test plan

• Verify the new TOC link #developer-sdks-and-cli resolves to the section header in the rendered README on GitHub.
• Verify all nine registry links open the correct package page.
• Verify all nine repo links open the correct GitHub repo.
• After PRs Add VERSIONING.md — SDK and CLI versioning policy #2/Add docs/sdks.md — public overview of the SDK suite #3/Add docs/cli.md — public CLI reference #4 merge, verify the relative links to VERSIONING.md, docs/sdks.md, and docs/cli.md resolve.

[pimfeltkamp]

Known issue surfaced post-PR

Iter-25 audit found that pub.dev/packages/cryptohopper returns 404 — the Dart SDK has never been uploaded to pub.dev (release workflow's publish step is commented out pending a one-time manual bootstrap). So the table's dart pub add cryptohopper claim is currently inaccurate.

Fix is in flight at cryptohopper/cryptohopper-dart-sdk#2, which adds a PUBLISHING.md checklist for the manual bootstrap. Until that bootstrap happens (dart pub publish from a workstation), the only working install method is a git dependency.

Two options for this PR:

1. Land as-is and accept that the Dart row is forward-looking until the one-time manual publish lands. (The other 8 rows all work today.)
2. Amend the Dart row to mark it as "coming soon" or to show the git-dependency form.

I'd lean (1) — once the bootstrap publish lands (a couple-minute task on Pim's machine) the row becomes accurate and there's no further README churn. Happy to amend if you'd rather have the README perfectly reflect the current registry state.

[pimfeltkamp]

Cross-link to PR #3 comment

Iter-41 audit found a pre-existing public cryptohopper-ios-sdk (Swift / CocoaPods / iOS-only, since 2020, 4 stars) that overlaps with the Swift row in this PR's table.

The new cryptohopper-swift-sdk (cross-platform via SwiftPM) is positioned differently, so they can coexist — but the README should ideally flag the difference so iOS-only mobile developers don't get confused. I've left a longer comment on PR #3 with the full picture of pre-existing SDKs in the org and suggested follow-ups.

Also worth adding to this PR's table: Kotlin / Android via the existing cryptohopper-android-sdk — currently absent from the install matrix.

Same as PR #3: I deliberately didn't amend this PR to avoid forcing a re-review. Happy to follow up with a small PR after this lands if you'd like the Android row + Swift caveat added.