[Enhancement] Allow attributes, like format_read, to have inlined code

Currently, various attributes like format_read require a string containing a function name as the argument. A lot of the time, these functions seem to end up being a simple one-liner.

// == current ==
struct DATE
{
    u16 year;
    u8 month;
    u8 day;
}
[[
    format_read("read_DATE"),
    transform("transform_DATE"),
    ...
]];
fn read_DATE(auto v)
{
    return std::format("{}-{}-{}", v.year, v.month, v.day);
};
fn transform_DATE(auto v)
{
    return (v.year * 10000) + (v.month * 100) + v.day;
};

This adds a decent amount of boilerplate overhead, making the underlying data format specification a little more difficult to read (due to tool integration 'noise'). Although the function could be moved to a different part of the pattern file, to somewhat separate data format from integration, the function would then no longer be co-located with the data it's operating on.

I feel things could be cleaner / clearer, if the contents of that function were optionally able to be inlined. This also avoids needing the pattern creator to make sure the function is uniquely named, as well as having to access the data through a (named) parameter.

As a first pass suggestion, inlining simple one-liners could look like:

// == proposed ==
struct DATE
{
    u16 year;
    u8 month;
    u8 day;
}
[[
    format_read(std::format("{}-{}-{}", year, month, day)),
    transform((year * 10000) + (month * 100) + day),
    ...
]];

Start by tracing how the format_read and transform attributes are parsed and applied, using the current and proposed DATE examples as the behavioral reference. Determine how inline expressions would receive struct fields and how existing named functions remain supported; done means both forms work without requiring uniquely named helper functions.