feature: add bybit demo trading option to README

[Romazes]

Description

Adds demo to the --bybit-use-testnet choice list in modules-1.14.json so users can pick Bybit's Demo Trading environment from the Lean live wizard. Regenerates the README command reference via scripts/readme.py to surface the new option.

Related PR(s)

QuantConnect/Lean.Brokerages.ByBit#41 — adds Bybit demo trading support in the brokerage itself (REST/WS URL routing, public-stream fallback to mainnet).

Related Issue

N/A

Motivation and Context

Bybit Demo Trading is a sandboxed account that uses real mainnet market data, distinct from testnet. With the brokerage-side support landing in Lean.Brokerages.ByBit#41, the CLI wizard needs a third option alongside live and paper so users don't have to hand-edit bybit-api-url / bybit-websocket-url to point at api-demo.bybit.com / stream-demo.bybit.com.

The corresponding modules-1.14.json entries (gitignored here, served from cdn.quantconnect.com/cli/) need to add:

"input-choices": ["live", "paper", "demo"]

plus URL filters mapping pattern: "demo" → https://api-demo.bybit.com and wss://stream-demo.bybit.com.

Requires Documentation Change

No (README is regenerated as part of this PR).

How Has This Been Tested?

• Locally edited lean/modules-1.14.json to add the demo choice and URL mappings.
• Ran python scripts/readme.py; verified --bybit-use-testnet [live|paper|demo] now appears in both lean live and lean live deploy sections of the README.
• Validated JSON with python -c "import json; json.load(open('lean/modules-1.14.json'))".
• Smoke-tested the wizard end-to-end against the brokerage from Lean.Brokerages.ByBit#41: picking demo routes orders to api-demo.bybit.com and the public market-data stream falls back to mainnet (wss://stream.bybit.com) as designed in the brokerage.

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>