Add SQLite output module

[r2unit]

Pre-Request Checklist

• [x] Passes rubocop code analysis
• [x] Tests added or adapted
• [x] Changes are reflected in the documentation
• [x] User-visible changes appended to CHANGELOG.md

Description

adds a new SQLite output module and fixes RuboCop violations to get CI passing.

SQLite Output Module

Adds support for storing device configurations in a SQLite database, similar to the existing file and git outputs. This is useful for deployments where you want versioned configs in a single portable database file.

Features:

• Stores all device configs in one database file
• Keeps version history (configurable, defaults to 100 versions per device)
• Works with groups
• Handles cleanup when devices are removed
• Uses WAL mode for concurrent access

Example config:

output:
  default: sqlite
  sqlite:
    database: ~/.config/oxidized/configs.db

RuboCop Fixes

Fixed all style violations to make CI happy:

• Cleaned up whitespace and formatting
• Fixed symbol array syntax
• Renamed some methods to follow conventions
• Fixed a syntax error (duplicate end statement)
• Aligned method chains consistently

Both features include tests and documentation updates.

[ytti]

Persistent state is something we definitely need. I'm just worried about the author's comprehension on what they are doing, as quick glance makes me feel this is very LLMy work. Quick glance didn't give me any obvious specific concerns, just LLMyness made me worry that lot of care will be needed to review.

[r2unit]

Thanks for the feedback, yes i've used claude for the boilerplate, rubocop fixes and also some other minor issues i encountered. But i've read through everything that got generated and tested it all. If there are specific things you think should've be done differently. Please let me know!

[robertcheramy]

An example:

BREAKING: State is now persisted to SQLite database instead of being stored in memory. Existing statistics will be lost on upgrade but will rebuild automatically.

Existing statistics are always lost on upgrade as they are being stored in memory. An LLM does not understand what it is doing. It does only outputs what statistically seams the best option. Using LLMs to speed up development is fine ("How do I concatenate an array of strings into one string in ruby?", "Can I write this code in an more elegant, concise way?" "Can you explain me what this code does?"). But the code should not only be fully be understood by the human, it should be (re)written by the human, as the only one who understands what he does.

The only thing I could do with this PR is use it as an inspiration for implementing a persistent state or an SQL Output - they are separate things that should probably be implemented separately. I would probably prefer starting from scratch and think about the best way to do it. Both are not in my top priority, so I will not review this PR.