Major cleanup and optimization: Remove unused dependencies, clean build artifacts, and improve project structure

- Remove 7 unused dependencies: apt-pkg-native, pkg-config, walkdir, lazy_static, futures, async-trait, cap-std
- Delete dead code: Remove unused parallel.rs module
- Clean build artifacts: Remove debian/cargo/, debian/.debhelper/, and other build files
- Update .gitignore: Comprehensive patterns for build artifacts, test files, and temporary files
- Move documentation: Relocate project docs to docs/ directory
- Remove test artifacts: Clean up test files and package archives
- Update Cargo.toml: Streamline dependencies and remove unused features
- Verify build: Ensure project still compiles after cleanup

This commit significantly reduces project size and improves build efficiency.

docs/aptvsdnf.md

@@ -0,0 +1,162 @@
+When we started this project we were using rust-apt.
+I see now we are using
+apt-pkg-native = "0.3.3"
+I am just curious what features caused you to chnage.
+
+Also, can you write up a report on how we made apt-ostree work like rpm-ostree when dnf has features not available in apt?
+
+A modest report on features DNF has that we could have used that are missing in apt.
+
+# DNF Library Features That May Need APT Equivalents
+
+## Overview
+When porting a Fedora tool that uses DNF libraries to Debian using `libapt-pkg7.0`, you'll need to identify which DNF-specific features the source application relies on and find equivalent implementations or workarounds.
+
+## Core DNF Library Features to Assess
+
+### 1. Transaction History Database
+**DNF Feature:**
+- Persistent SQLite database tracking all package operations
+- Each transaction has unique ID with timestamp, user, and package lists
+- Programmatic access to historical transactions
+
+**Source App Might Use:**
+```python
+# DNF library calls
+base.history.list()
+base.history.get_transaction(tid)
+base.history.undo_transaction(tid)
+```
+
+**APT Equivalent Considerations:**
+- APT logs to flat files (`/var/log/apt/history.log`, `/var/log/dpkg.log`)
+- No built-in transaction IDs or structured database
+- You'd need to parse log files or implement your own transaction tracking
+
+### 2. Atomic Transaction Operations
+**DNF Feature:**
+- Operations grouped as atomic units
+- Built-in rollback capabilities
+- Transaction state validation
+
+**Source App Might Use:**
+```python
+transaction = base.transaction
+transaction.install(package)
+transaction.remove(package)
+# All operations happen together or not at all
+```
+
+**APT Considerations:**
+- APT operations are not inherently atomic
+- No built-in rollback mechanism
+- You'd need to implement transaction grouping yourself
+
+### 3. File-to-Package Resolution
+**DNF Feature:**
+- Built-in file/capability to package mapping
+- No external tools required
+
+**Source App Might Use:**
+```python
+base.sack.query().filter(file="/usr/bin/htop")
+```
+
+**APT Equivalent:**
+- Requires `apt-file` or parsing `Contents` files
+- More complex implementation needed
+
+### 4. Package Groups/Collections
+**DNF Feature:**
+- Native support for package groups
+- Group metadata in repositories
+
+**Source App Might Use:**
+```python
+base.group_install("Development Tools")
+base.group_remove("Desktop Environment")
+```
+
+**APT Considerations:**
+- APT uses "tasks" and "metapackages" instead
+- Different conceptual model
+- May need mapping logic
+
+### 5. Module/Stream Support (Historical)
+**DNF Feature:**
+- Support for software modules with multiple streams
+- Version/stream switching capabilities
+
+**Note:** This was deprecated in recent Fedora versions, but older tools might still use it.
+
+### 6. Repository Metadata Handling
+**DNF Feature:**
+- Rich metadata format (repodata)
+- Dependency solver information
+- Update advisory data
+
+**Source App Might Access:**
+```python
+base.fill_sack()  # Load all repository metadata
+base.sack.query().updates()  # Find available updates
+```
+
+**APT Considerations:**
+- Different metadata format (`Packages`, `Release` files)
+- May need format conversion or abstraction layer
+
+### 7. Plugin System Integration
+**DNF Feature:**
+- Extensive plugin architecture
+- Hooks for pre/post operations
+
+**Source App Might Use:**
+```python
+# Plugin hooks
+dnf.plugin.post_transaction()
+dnf.plugin.pre_transaction()
+```
+
+**APT Considerations:**
+- Limited plugin system
+- May need custom hook implementation
+
+## Implementation Strategy Considerations
+
+### Direct Feature Mapping
+Some features have reasonable APT equivalents:
+- **Package installation/removal** - Direct mapping
+- **Dependency resolution** - APT's resolver is capable
+- **Repository management** - Similar concepts
+
+### Features Requiring Workarounds
+These will need custom implementation:
+- **Transaction history** - Parse APT logs or implement tracking
+- **Rollback operations** - Custom state management
+- **File-to-package mapping** - Integrate apt-file or build index
+
+### Features That May Not Apply
+- **RPM-specific operations** - May not be relevant for DEB packages
+- **Module streams** - Debian doesn't use this model
+- **Group installations** - Different paradigm in Debian
+
+## Practical Assessment Questions
+
+To identify what you'll actually need to implement:
+
+1. **What specific DNF library calls does the source application make?**
+2. **Does it use transaction history features?**
+3. **Does it rely on package groups or modules?**
+4. **How does it handle repository metadata?**
+5. **Does it use DNF's plugin system?**
+6. **What error handling does it expect from DNF operations?**
+
+## Recommendation
+
+I'd suggest:
+1. **Audit the source code** for actual DNF library usage
+2. **Create an abstraction layer** that maps DNF calls to APT equivalents
+3. **Identify features that need custom implementation** vs. direct mapping
+4. **Test with representative use cases** to ensure behavior matches
+
+Would you be able to share what specific DNF library features the source application actually uses? That would help provide more targeted guidance on the APT implementation approach.