refactor(theme): color definitions to use vim.g directly

[NopAngel]

Changes

Performance: Replaced vim.api.nvim_eval calls with vim.g for faster and more idiomatic access to global variables.

Robustness: Added fallback logic for specific Srcery colors (orange, hardblack, etc.) to ensure the theme doesn't break if certain globals are missing.

Code Quality: Cleaned up redundant section definitions by using local variables (DRY principle).

Formatting: Followed the project's comment style and structure.

[roosta]

Hi there, thanks for opening a PR, this looks good, no need to call eval when we already have the globals. Thoughts @MindTooth? Im good with a merge.

[MindTooth]

If this speeds up, I am all in.

is this something that we can extend to more languages? Don’t have to do that now

[roosta]

there are no other eval calls in codebase that I can find, but there are places where we can replace srcery#helper#GetColor with global variables. In the lightline theme for example. I've already made that change in the next branch (modernize)

[roosta]

Whats going on with the linter check here? Seems it never runs on external PRs like this, is it suppose to? Should I just bypass it?

[MindTooth]

I will check pipeline tonight. Maybe $default-branch is not a valid parameter.

[roosta]

here's what I did to fix the lint job on feat/modernize 9ce323f we should probably backport that fix, I'll just rebase atop the master when its done.
EDIT: Vimjas/vint#394

[MindTooth]

I just merged it should be good.

Thanks! ❤️