Python doc edits for #8336

[audrey-serpapi]

Updates to unify integration doc structure #8336
Summary of changes:

• Added: Features, Response Formats, Configuration, Search Asynchronous, new examples
• Edited: Quickstart
• Reordered: examples, headers like Documentation
• Removed: 'Markdown output for AI agents' section (as it was already included in the response formats section) + some examples to keep the API spotlighted consistent

[strzibny]

Thank you @audrey-serpapi in looking into this. I have some comments.

Styling-wise:

1. Let's only use sentence case
2. Prefer bold text (Google Shopping Light) instead of #### headings for light variants
3. "See documentation" not "See Documentation"
4. Let's drop $ from examples so they are easier to copy (and follows Ruby README), e.g. pip install serpapi not $ pip install serpapi

Text inconsistencies:

1. os.getenv("API_KEY") vs export SERPAPI_KEY (ENV needs to be same everywhere)
2. indentation switches between 2 and 4 spaces
3. import order varies.
4. Quickstart links to /dashboard instead of users/sign_up?plan=free
5. "See the playground" has no link.

Technically wrong for Python:

1. "Set defaults when creating a client, then override search parameters in individual calls" is not possible in Python. This is only a feature of our Ruby library.
2. The engine and async rows ("can be set on the client") are wrong. Neither can be set on the client.
3. The timeout default is not 120. It’s None, which means requests has no timeout at all. (I am thinking if we should add it @adarshdigievo)
4. "for non-persistent HTTP requests" doesn’t apply here as Python always uses a requests.Session.
5. "Search-engine-specific parameters can also be supplied when creating the client" is false.
6. "returns the results as a regular Python Hash": “Hash” is Ruby terminology. Python has dictionary.
7. "a Python Dictionary" should be dict.
8. the section with 'This strategy is I/O usage' doesn't read well, also, in Python people might use concurrent.futures.ThreadPoolExecutor instead of forking, maybe let's write it more generally (" a single process can submit many searches and collect the results later. The code is more complex because you have to track search IDs and check their status.")