Add distinct error codes based on failure origin

[enzofrnt]

What would you like to be added:

A more granular error code system based on the origin of the error.
For example, if an issue occurs due to a problem in the input file provided to Grype, it should result in a different error code than when Grype is unable to reach its upstream server or database.
This differentiation would make it easier to diagnose and handle failures programmatically or during debugging.

Why is this needed:

Currently, when Grype fails, the error output is sometimes vague and the exit code does not reflect the nature of the problem.
By assigning distinct error codes to common failure categories (e.g. network issues, file format issues, configuration errors, etc.), it would become easier to:

• Build reliable CI/CD pipelines
• Improve developer experience during integration
• Quickly identify and fix errors

Additional context:

This feature would be especially useful when Grype is integrated into automated environments or security pipelines, where error handling needs to be robust and clearly distinguishable.

[wagoodman]

Quick proposal of the classes of failures we might want to capture:

• 10: Config or input issues
• 11: Database issues
• 12: Scan target issues
• 13: Analysis could not complete

And as noted by @willmurphyscode we want to avoid return code 2 as that is reserved for identifying golang panics. This could be a breaking change for existing users so we should defer this work to grype 1.0.