Performance and Code Quality Improvements: Regex Optimization and Refactoring

Summary

This PR introduces significant performance improvements and code quality enhancements through regex compilation optimization, code de-duplication, and some minor structural refactoring.
The changes move repeatedly compiled regex patterns to compile-time constants and implement several architectural improvements.

Aimed to keep the revset fairly small to make it easy to review, let me know if it's a bit much much.

The Short & Sweet / tl;dr / lgtm - Technical Improvements

• Replaced runtime Regex::new() calls with static LazyLock<Regex> patterns
• Implemented EnvVarProcessor trait for cleaner environment variable handling
• Consolidated platform-specific file extension logic into compile-time constants
• Mild improvements to error handling patterns and reduced code duplication

Key Changes

Perf. Optimizations

• Regex compilation: Moved all regex patterns from runtime compilation to compile-time static constants using the std lib's LazyLock.
  The docs for the std lib's Regex mention that regex compilation is an expensive operation, and compiling regex patterns at runtime run every time they're read in.
  This can be especially rough on performance in hot-loops. (I've always treated it as a case of 'if you can move it to compile time, do it'. (Such is Rusts philosophy anyway.))

  This will also remove any potential overhead bob may have been encountering when making repeat calls to the functions.

• New constants module: Created 'src/consts.rs' with centralized regex patterns (VERSION_REGEX, NIGHTLY_REGEX, ENVIRONMENT_VAR_REGEX)
  Moving Regex to compile time is of course the primary reason for the PR; however, centralizing also makes it easier to maintain & write tests for in the future.

• Platform specific constants: Introduced FILETYPE_EXT constants for platform-specific file extensions ('tar.gz' vs. 'zip')
  This was previously a function call with an internal cfg!(target_family = _ ) macro call.
  Given the function call only exists to make an if-else decision based on a compile-time flag set by cargo, it makes sense to move this to be just a straight-up constant instead.
  Conditional compilation can still be expanded via 'target_os' vs 'target_family' etc. or the function re-implemented again later if needed.

Code Structure & Quality

• Env. Variable processing: Refactored config.rs to use a polymorphic trait-based approach, favoring array->trait(), which is more idiomatic in Rust and should also make it easier
  to extend in the future if bob decided to further support Environment Variables without moving towards something like the config crate.

• install_handler.rs cleanup: Minor streamlining for readability, extracting the progress bar logic into PbWrapper struct, very minor code organization done in src/handlers/install_handler.rs
  Note: Had I more time, I would have liked to have done a more thorough refactor of the install_handler.rs file (ie: cleaning up boolean flags & preferring type-heavier pattern-matching).
  That being said this PR was mostly to resolve the Regex, so I didn't want to go too far off the beaten path.

• Import path standardization: Consistently prefer crate::* over super::* import calls throughout the codebase.
  super::<> as a preference becomes a lot harder to manage if a project grows in size, with refactoring becoming a pain point due to imports when moving files around.

Note: I'd like to highlight that these specific changes did involve modifications to the #[cfg(test)] module items in src/helpers/mod.rs - by way of removal of the prefixed super:: and moving that to the module level.
I've run tests locally (via Arch-Linux) and they all pass and I've used the binary to do installs/uninstalls etc.

Performance Impact

• Elimination of runtime Regex compilation: Previously regex patterns were compiled on call; they're now compiled once at compile time
• Reduced memory allocations: Static patterns reduce heap allocations during regex operations (I've also attempted to minimize cloning and other allocations where possible)
• Code maintainability/readability: Centralized constants make regex patterns easier to maintain and modify