Add comprehensive documentation and examples for Owlen architecture and usage

- Include detailed architecture overview in `docs/architecture.md`.
- Add `docs/configuration.md`, detailing configuration file structure and settings.
- Provide a step-by-step provider implementation guide in `docs/provider-implementation.md`.
- Add frequently asked questions (FAQ) document in `docs/faq.md`.
- Create `docs/migration-guide.md` for future breaking changes and version upgrades.
- Introduce new examples in `examples/` showcasing basic chat, custom providers, and theming.
- Add a changelog (`CHANGELOG.md`) for tracking significant changes.
- Provide contribution guidelines (`CONTRIBUTING.md`) and a Code of Conduct (`CODE_OF_CONDUCT.md`).

docs/testing.md

@@ -0,0 +1,58 @@
+# Testing Guide
+
+This guide provides instructions on how to run existing tests and how to write new tests for Owlen.
+
+## Running Tests
+
+The entire test suite can be run from the root of the repository using the standard `cargo test` command.
+
+```sh
+# Run all tests in the workspace
+cargo test --all
+
+# Run tests for a specific crate
+cargo test -p owlen-core
+```
+
+We use `cargo clippy` for linting and `cargo fmt` for formatting. Please run these before submitting a pull request.
+
+```sh
+cargo clippy --all -- -D warnings
+cargo fmt --all -- --check
+```
+
+## Writing New Tests
+
+Tests are located in the `tests/` directory within each crate, or in a `tests` module at the bottom of the file they are testing. We follow standard Rust testing practices.
+
+### Unit Tests
+
+For testing specific functions or components in isolation, use unit tests. These should be placed in a `#[cfg(test)]` module in the same file as the code being tested.
+
+```rust
+// in src/my_module.rs
+
+pub fn add(a: i32, b: i32) -> i32 {
+    a + b
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_add() {
+        assert_eq!(add(2, 2), 4);
+    }
+}
+```
+
+### Integration Tests
+
+For testing how different parts of the application work together, use integration tests. These should be placed in the `tests/` directory of the crate.
+
+For example, to test the `SessionController`, you might create a mock `Provider` and simulate sending messages, as seen in the `SessionController` documentation example.
+
+### TUI and UI Component Tests
+
+Testing TUI components can be challenging. For UI logic in `owlen-core` (like `wrap_cursor`), we have detailed unit tests that manipulate the component's state and assert the results. For higher-level TUI components in `owlen-tui`, the focus is on testing the state management logic rather than the visual output.