Add `file_headers` attachment handler

We currently have a file_content attachment handler that adds the entire output of a file as an attachment to the conversation. This works, but as projects (such as jp) grow, it first becomes more expensive, and eventually impossible to embed the entire project's code base as context in a conversation.

There is a trade-off between spending time on this, vs. waiting for context windows to increase in modern LLM implementations and the cost/token to go down as more competition enters the market. However, I don't expect either of these two to change as rapid as we need them to, so I suggest we start tackling some of these problems at JP's end as well.

Of course, there are many routes to take, and there are higher-level features such as "repository maps" that we can (and should) investigate as well, but to start, let's focus on an attachment handler that produces "headers" of any given file.

What a header is depends on the programming language used for a file, but initially, we'll focus on Rust, defining a header file as a file that contains all code and comments in a file except for function/method implementation blocks.

Meaning, this:

/// The `Foo` struct!
struct Foo {
  bar: bool
}

/// Create a new [`Foo`]
fn new_foo() -> Foo {
    Foo { bar: false }
}

Is turned into this:

/// The `Foo` struct!
struct Foo {
  bar: bool
}

/// Create a new [`Foo`]
fn new_foo() -> Foo;

Obviously, in this trivial example that's only a 2-line difference, but in real-world examples, function implementations can take up to 50% of the total (non-test-code) file size. Additionally, we can consider (or make it configurable) whether #[test] cfg'd code should be excluded as well (which, for a well-tested project, can also be 50% of the total file size)

Start by locating the existing file_content attachment handler and the Rust code that registers attachment handlers. Review how files are read and how Rust syntax can be identified, then define the file_headers behavior from the issue's example. Done means a handler can produce Rust headers without function implementation blocks, with any test-code treatment decided and covered by tests.