feat(complex) Add complex number support for the @std/math library

[Definitely-Not-A-Dolphin]

No description provided.

[CLAassistant]

All committers have signed the CLA.

[codecov]

Codecov Report

❌ Patch coverage is 4.65116% with 205 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.24%. Comparing base (cd03740) to head (4888869).

Files with missing lines	Patch %	Lines
math/complex.ts	4.20%	204 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7122      +/-   ##
==========================================
- Coverage   94.61%   94.24%   -0.38%     
==========================================
  Files         634      635       +1     
  Lines       51799    52014     +215     
  Branches     9329     9330       +1     
==========================================
+ Hits        49009    49019      +10     
- Misses       2216     2420     +204     
- Partials      574      575       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Definitely-Not-A-Dolphin]

Excuse me for my bad commit messages earlier, I forgot that this was a professional setting. A few topics of discussion here:

Structure

The entire module contains a Complex class that is used to create complex numbers. The functions for complex numbers, (arithmatic, absolute value, argument, trig) are static methods on that class. I made that decision for two reasons:

1. The "real" number functions are collected in the Math namespace, so I thought it made sense to collect all the complex number functions in a Complex object.
2. When importing the class, you don't have to import 30 different functions seperately, which looks bad and is terrible for name collisions.

Documentation

The deno contributing guidelines state that when applicable, all exported symbols must be documented according to the following rules:

1. A short description, then any further details in new paragraph(s).
2. A @typeParam tag for each type parameter.
3. A @param tag for each parameter.
4. A @returns tag for the return value.
5. At least one example code snippet using the
   @example tag and a title. For simple
   examples which don't need a description, "Usage" is an acceptable title. See
   Example code snippets below for further guidance.

The first rule I understand, but the rules about the JSDoc documentation feel a bit unnecessary to me. Unlike all the other libraries, which are about programming / computer topics, this is math. Function names about computer topics are always at least a little vague, but math functions aren't. Sine is always sine, without any ambiguity.

Also, is it really necessary to include example cases for all 24 trig functions? Not only are there a lot of them, they are all pretty abstract. I don't think that adding examples would be of any additional value.

Trig function names

Should inverse trig functions be called asin, acos, atan, or arcsin, arccos, arctan? My math side says the latter, but my computer side says the former.

[Definitely-Not-A-Dolphin]

This PR is also a draft because

1. I still need to write test cases, and
2. The above mentioned discussions still need to be done