Fix search with non-ASCII terms by removing manual '+' substitution

[ParkJeongseop]

Fix search with non-ASCII terms by removing manual + substitution

Summary

AppleMusic.search() silently returns unrelated results when the term contains non-ASCII characters (Korean, Japanese, Chinese, etc.). Root cause is a pre-processing step that conflicts with how requests encodes query parameters. This PR removes the broken pre-processing and lets requests handle URL encoding directly, fixing searches for all languages. The now-unused os parameter ('linux' / 'windows') is removed as well, since both branches were workarounds for the same underlying bug.

What changed

• Fix (non-ASCII search) — Removed term = re.sub(' +', '+', term) from search() and let requests handle URL encoding end-to-end. The pre-substitution conflicted with requests' percent-encoding for non-ASCII terms: + got re-encoded to %2B, the server decoded it back as a literal +, the query matched nothing, and the API silently fell back to returning trending results with 200 OK.
• os parameter removed — The os='linux' / os='windows' branches were a workaround for the same bug above, not a real OS-compatibility layer. The name was misleading: behavior was determined entirely by whether the term contained non-ASCII characters, not by the operating system. With the pre-substitution gone, both branches become identical, so the parameter has no remaining purpose.
• Cleanup — Dropped the now-unused import re in client.py, and removed test_search_windows in tests.py (it exercised the deleted os='windows' path).

Backward compatibility

AppleMusic.search() no longer accepts the os keyword argument. Callers passing os='linux' or os='windows' will see:

TypeError: search() got an unexpected keyword argument 'os'

Mitigation is to simply drop the argument — the default path now works correctly in every environment and for every language, so no alternative is needed.

No other public API changes. song(), album(), songs_by_isrc(), etc. are untouched.

Verification

Reproduction against live Apple Music API (Korean phrase "Landing in Love"):

import applemusicpy
am = applemusicpy.AppleMusic(secret_key, key_id, team_id)

results = am.search('사랑하게 될 거야', storefront='kr', l='ko-KR',
                    limit=5, types=['songs'])
for s in results['results']['songs']['data']:
    attrs = s['attributes']
    print(f"{attrs['name']} / {attrs['artistName']}")

Before:

Vancouver / BIG Naughty
Hype Boy / 뉴진스
11:11 / 태연
...

After:

사랑하게 될 거야 / 한로로
사랑하게 될 거야 / 온앤오프
사랑하게 될 거야 (2022 Remastered Version) / 온앤오프
...

Same symptom reproduces with any non-ASCII term (e.g. '恋をしたのは', '愛してる'). ASCII terms "worked" before only because requests happened to leave + intact in those cases, which the server then interpreted as a space — effectively masking the underlying bug for English searches.

Test plan

• Existing test_search passes
• Korean term '사랑하게 될 거야' (storefront='kr', l='ko-KR') returns correctly matched tracks against the live API
• English term 'IU' returns expected tracks — no regression
• songs_by_isrc(['USUM71410382']) returns the expected three Adam Levine tracks — no regression (songs_by_isrc uses a different endpoint, included as a sanity check that the broader client is unaffected)