Add compression for output file with gzip and MessagePack. Add inbuil…

[rahlk]

Add output format flag with MessagePack compression support

Address issue #6 by implementing a --format flag that allows users to choose between compact JSON and ultra-compressed MessagePack output formats, achieving 80-90% size reduction for large analysis results.

Motivation and Context

Large Python codebases generate analysis results that can be several megabytes in size when output as pretty-printed JSON. This creates problems for:

• Storage efficiency: Large files consume unnecessary disk space
• Transfer speed: Slow uploads/downloads in CI/CD pipelines
• Processing performance: Large JSON files are slower to parse
• Network bandwidth: Inefficient for distributed analysis workflows

This change addresses these issues by providing format options optimized for different use cases while maintaining full data fidelity.

How Has This Been Tested?

• ✅ Real codebase testing: Tested on large Python projects (1000+ files)
• ✅ Format validation: Both JSON and MessagePack outputs validated
• ✅ Round-trip testing: Serialization → deserialization preserves all data
• ✅ Compression verification: Confirmed 80-90% size reduction on real data
• ✅ Error scenarios: Invalid format options handled gracefully
• ✅ Backward compatibility: Existing workflows continue unchanged

Example compression results on real project:

❯ uv run codeanalyzer --input $PWD -vvv --output /tmp --format=msgpack --keep-cache
Building symbol table ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 21/21 files 0:00:04 0:00:00
[07/11/25 00:41:57] INFO     ✅ Symbol table generation complete.
                    INFO     Analysis saved to /tmp/analysis.msgpack
                    INFO     Compression ratio: 9.2% of JSON 

Breaking Changes

None. This is a fully backward-compatible addition:

• Default behavior remains unchanged (compact JSON output)
• All existing CLI commands work exactly as before
• No changes to programmatic APIs

Types of changes

• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the [Codellm-Devkit Documentation](https://codellm-devkit.info)
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

N/A