suggestion: don't use std/assert in implementation code #4865

Using assertions from std/assert within implementation code in the codebase has a few drawbacks:

1. In cases where the user needs to error handle an API that uses assertions from std/assert, they need to import and use AssertionError.
2. While error messages provide the majority of the context behind an error, the constructor name does, too. I.e. RangeError. AssertionError is generic and doesn't add any context to the error.
3. It introduces an added dependency. In most cases, this doesn't matter. But for some, it does.

For these reasons, I suggest that we remove the use of assertions from std/assert within the implementation code in the Standard Library and instead use native error classes where possible. In cases where these native error classes do not fit, we can create and export custom error classes that extend Error. Doing so requires minimal code changes and can be more explicit than calling a generic assertion.

• refactor(async): cleanup use of @std/assert #4950
• refactor(fs): cleanup use of @std/assert #4948
• refactor(cli): cleanup use of @std/assert #4966
• refactor(jsonc): cleanup use of @std/assert #4968
• refactor(log): cleanup use of @std/assert #4973
• refactor(http): cleanup use of @std/assert #4974
• refactor(archive): cleanup use of @std/assert #4975
• refactor(csv): cleanup use of @std/assert #4976
• refactor(text): cleanup use of @std/assert #4977
• refactor(webgpu): cleanup use of @std/assert #4978
• refactor(io): cleanup use of @std/assert #4979
• refactor(streams): cleanup use of @std/assert #4980
• chore: document design decision to only use @std/assert within testing code #5516