[epic] migrate Soroban RPC to soroban-rpc Repository

[stellarsaur]

See #1115 for motivation behind separating Soroban RPC from Soroban CLI.

This issue tracks all work that needs to be done to completely separate Soroban RPC.

Done

• Create soroban-rpc repository (#1824)
• Migrate Soroban RPC codebase into soroban-rpc repository
• Remove code from soroban-rpc that isn't related to Soroban RPC (see soroban-rpc#5)
• Update Jenkins release jobs (e.g. soroban-rpc-docker-builder) to point to soroban-rpc repository (see pipelines#685)
• Update System Tests to point to new soroban-rpc repository (see soroban-rpc#6)
• Update Quickstart to point to new soroban-rpc repository (see quickstart#558)
• Update release process for Soroban RPC (see soroban-rpc#6)
• Move open Soroban RPC issues to soroban-rpc repository
• Update all public (and internal) docs that reference RPC to point to the new repo (see this PR)
• Merge/close all outstanding PRs for Soroban RPC in soroban-tools and add changes to soroban-rpc (see this PR)
• Add workflows to publish soroban-rpc crate (see this PR)
• Remove Soroban RPC code from soroban-tools (see this PR)
• Update release process for Soroban CLI (see this PR)

In Progress

To do

[leighmcculloch]

[ ] Migrate Soroban RPC codebase into soroban-rpc repository

It should be possible to preserve the git history of soroban-rpc. There are a couple ways that can be done while preserving the git history.

1. Simply push the soroban-tools repo to the soroban-rpc repo, so you have the entire history as is, then start deleting files and moving them around. By far the simplest, and you'll keep all past history including sha's exactly which is nice.

2. Use more complex git commands to retain the history without any of the other components. There's an example of how to do that here: https://github.com/stellar-deprecated/bridge-compliance?tab=readme-ov-file#bridge-and-compliance. This would end upwith a nicer looking history probably, but with all the SHAs changed which is annoying.

I think (1) could be a good approach for this, but defer to you.

[stellarsaur]

Considering the main repo migration complete now. Any additional tasks like updating workflows can be tracked separately.