feat: migrate off of tslint and use eslint

[parker-snyk]

What does this PR do?

TSLint has been deprecated since 2019.
This PR migrates us to ESLint, which is still supported, and has more features and support

Any background context you want to provide?

This shouldn't have any downsteam effects for anyone using this library. It just lets us lint better and move faster for development on this project

What are the relevant tickets?

https://snyksec.atlassian.net/browse/CN-934

Screenshots

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Disabled Safety Rules 🟡 [minor] The ESLint configuration explicitly disables several important rules, such as no-shadow, @typescript-eslint/no-shadow, and @typescript-eslint/no-explicit-any. While this might align with previous TSLint configurations, no-shadow helps prevent variable naming conflicts that can lead to subtle bugs, and @typescript-eslint/no-explicit-any is crucial for maintaining type safety in a TypeScript codebase. Re-enabling or carefully considering these rules could improve code quality and prevent future issues, rather than relying solely on developer vigilance. "no-shadow": "off", "@typescript-eslint/no-shadow": "off", "@typescript-eslint/naming-convention": "off", "no-bitwise": "off", "max-classes-per-file": "off", "no-console": "off", "@typescript-eslint/no-explicit-any": "off", "no-case-declarations": "off", "no-useless-escape": "off", "no-prototype-builtins": "off", "@typescript-eslint/no-require-imports": "off", "@typescript-eslint/no-namespace": "off", "no-control-regex": "off", Loose Unused Var Check 🟡 [minor] The @typescript-eslint/no-unused-vars rule is configured with caughtErrors: "none". This setting means that caught error variables will not be flagged as unused, even if they are genuinely not used within the catch block. While this might be intended to avoid linting errors for empty catch blocks, it can hide cases where an error object is passed but not utilized, potentially leading to missed debugging opportunities or silent failures. Consider setting caughtErrors to 'all' or 'auto' if there's an expectation that caught errors should be handled or logged. caughtErrors: "none",

📚 Repository Context Analyzed This review considered 21 relevant code sections from 13 files (average relevance: 0.87) package.json (lines 1-104) lib/analyzer/static-analyzer.ts (2 segments, lines 1-91) lib/dockerfile/index.ts (lines 1-61) lib/scan.ts (lines 1-247) lib/extractor/index.ts (lines 1-230) lib/inputs/rpm/static.ts (lines 1-108) package-lock.json (lines 6782-7005) ... and 6 more file(s)