Downgrade Lint Errors to Warnings @osterman (#1132)

## What - Downgrade some common lint errors to warnings. - Change reviewdog to only report annotations - Add a `lint-failures` label if it failed linting

Why

• Strict enforcement significantly increase scope on some PRs
• We need incremental improvements to code quality rather than blocking progress.
• Warnings should still be addressed, but they shouldn't block PR merges, if necessary
• Instead of lowering the bar, we keep the bar high informing developers of best practices.

Summary by CodeRabbit

• Chores
  • Updated the CI lint reporting to display issues as inline annotations for clearer visibility.
  • Refined lint configuration to enforce best practices and adjust severity levels, helping prioritize critical issues while reducing noise in code reviews.
  • Introduced a new parameter for specifying the version of the reviewdog tool used in the linting process.
  • Enhanced error handling in CI to label pull requests with "lint-failures" when lint errors are detected.

Warn on Excessive Function Returns & `//nolint` Usage @osterman (#1131)

## What - Warn when functions return more than 2 values (we should be returning objects). - Warn when using lint ignore (`//nolint`), so that we draw attention to it.

Why

• Objects have named properties, making it easier to understand what everything is. We've seen functions returning 7+ values, which is impractical and error-prone.
• Many times when //nolint is used, there’s a better way to address the issue:
  • The lint rule might be too strict.
  • The developer might not realize there's a straightforward solution that avoids ignoring the rule.
  • The rule may have been misunderstood.
  • The ignore might have been intended as temporary but was never revisited.

Summary by CodeRabbit

• Chores
  • Enhanced internal code quality checks to promote cleaner code practices.
  • Introduced stricter guidelines for function signatures to ensure improved maintainability.