Make SC a proper D enum

[dkorpel]

Remove casts, improve type safety of function signatures, make the field readable in a debugger.

[dlang-bot]

Thanks for your pull request and interest in making D better, @dkorpel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#14399"

[benjones]

What's the point of making it an enum if you then unwrap everything into a separate list of constants?

D needs dlang/projects#88

ping @WalterBright

I assume that's just to keep this PR/diff small? I assume those enums could be removed and replaced with SC.whatever piece by piece now?

[maxhaton]

Lots of important refactorings start with small "pointless" PRs. (1+1/n)^n limits to e not zero

[dkorpel]

What's the point of making it an enum if you then unwrap everything into a separate list of constants?

I listed the advantages in my PR comment. Separate constants are to keep the diff smaller.

D needs dlang/projects#88

Please don't discuss that here, you can link to this PR in the appropriate thread if it's relevant for your arguments.