feature: add clear street brokerage integration

[Romazes]

Description

Adds Clear Street to the live deployment commands. The change is the regenerated README.md, because the module itself is described in modules-1.14.json, which this repository does not track.

The module is a brokerage only. Clear Street has no market data websocket and no historical bars endpoint, so it declares no data-queue-handler, no history-provider and no data-downloader. It asks for three values:

--clearstreet-access-token TEXT            Your Clear Street API access token
--clearstreet-account-id TEXT              Your Clear Street account id
--clearstreet-order-poll-interval-ms INT   How long the brokerage waits between two reads
                                           of your orders, in milliseconds (Optional).

The API address is an internal input, so nobody is asked for it. The poll interval is optional and falls back to 3000 milliseconds, because Clear Street sends no order events and the brokerage reads the orders on a timer.

Related PR(s)

N/A

Related Issue

N/A

Motivation and Context

Without this, lean live deploy and lean cloud live deploy do not offer Clear Street, so the plugin cannot be used from the CLI.

Requires Documentation Change

The brokerage needs its own page under the live trading brokerages section, like the other brokerages have.

How Has This Been Tested?

• Loaded the module through the CLI loader. cli_brokerages and cloud_brokerages each resolve one Clear Street module, and get_configs_for_options returns the access token, the account id and the poll interval for a local run, and the first two for a cloud run.
• Checked the optional poll interval on both paths. An empty answer at the prompt gives the integer 3000, and a non interactive run takes the default the same way.
• README.md was regenerated with scripts/readme.py. The change is 11 added lines and 2 replaced lines, all of them Clear Street.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>