Generate const fn accessors with const_fn

[gerasim13]

What

Adds a const_fn setting that makes fieldwork generate const fn accessors.

#[derive(fieldwork::Fieldwork)]
#[fieldwork(get, get_mut, const_fn)]
struct Counters {
    /// how many times this has happened
    count: usize,
}

const fn read(c: &Counters) -> usize {
    c.count()
}

It is an ordinary cascading boolean, so it resolves through the usual four
levels — field-method, field, item-method, item — and can be turned on for a
whole type and off for one field, or the other way round:

#[fieldwork(get)]
struct Mixed {
    /// borrowed by an ordinary getter
    name: String,
    /// read in a const context
    #[field(const_fn)]
    port: u16,
}

Why

An accessor that copies a Copy field out of &self, or returns &mut to
it, is already inside the const subset — but the generated method is a plain
fn, so a type whose fields are private cannot be read from a const item
at all through its own API. Today that means keeping hand-written const
accessors next to the derived ones, which is exactly the duplication the
derive exists to remove.

Notes

• Opt-in, defaults to false: no existing generated code changes.
• Spelled const_fn, not const, because const is a reserved word and
  does not parse as a path inside the attribute's expression list.
• Whether the body is const is left to the compiler rather than being
  pre-validated by the macro: deref calls Deref::deref, into calls
  Into::into, and a setter drops the previous value, so those combinations
  produce a normal const-eval error pointing at the generated method.
  docs/const_fn.md spells this out.

Tests

• New expansion snapshot tests/expand/expand_29_const_fn.rs covering the
  item-level and field-level forms over get and get_mut.
• tests/ui/invalid_config.stderr updated: const_fn now appears in the
  recognized-key list.
• New docs/const_fn.md, included under #[cfg(doc)] like the other topic
  pages; cargo run -p docs-gen -- --verify is clean.

cargo test --all passes. cargo clippy --all-targets -- -Dwarnings reports
the same 13 findings before and after this change on my toolchain (all in
files this PR does not touch), so I left them alone.

[jbr]

Looks good, thank you!