feat: Add config options to customize header field names

[froq0]

Is your feature request related to a problem? Please describe.

I'm working with multiple Neovim plugins to manage file headers, and I've encountered a limitation with field name customization. Currently, header.nvim uses fixed field names (e.g., "Date modified:", "File name:", "Author:") defined in config.lua constants. However, different users and projects may have different conventions for these field names.

For example, I maintain headup.nvim, a plugin that automatically updates header metadata fields on save. I prefer using "Last Modified:" instead of "Date modified:" for consistency with my existing documentation conventions and workflows. Currently, there's no way to customize these field names, which creates inconsistency when these two plugins work together, and may not align with various coding standards or personal/organizational preferences.

Describe the solution you'd like

I propose adding configuration options to allow users to customize the field names used in headers. Following the existing configuration naming pattern in header.nvim, this could be implemented by adding *_key suffix options:

require("header").setup({
    -- existing config options...
    file_name = true,
    file_name_key = "File:",  -- custom field name instead of default "File name:"
    
    author = "John Doe",
    author_key = "Author:",   -- custom field name instead of default "Author:"
    
    project = "my-project",
    project_key = "Project:", -- custom field name instead of default "Project:"
    
    date_created = true,
    date_created_fmt = "%Y-%m-%d %H:%M:%S",
    date_created_key = "Created:",  -- custom field name instead of default "Date created:"
    
    date_modified = true,
    date_modified_fmt = "%Y-%m-%d %H:%M:%S",
    date_modified_key = "Last Modified:",  -- custom field name instead of default "Date modified:"
})

This approach:

• Maintains consistency with existing configuration patterns (e.g., date_created_fmt)
• Allows each field to have a corresponding *_key option for customization
• Keeps the implementation clean and intuitive
• Has zero breaking changes - if *_key is not specified, use the default from constants

Describe alternatives you've considered

1. Using a nested field_names object: This would group all customizations but breaks the flat configuration pattern used throughout the plugin.

2. Forking the plugin: Users could fork and modify config.lua directly, but this makes it harder to receive updates and creates maintenance overhead.

3. Post-processing with autocmds: Users could write autocmds to search and replace field names after insertion, but this is inefficient and error-prone.

Additional context

This feature would enhance plugin composability and allow header.nvim to work seamlessly with other header management tools like headup.nvim. It would also accommodate different coding standards across organizations and languages (e.g., some projects use "Modified:" while others prefer "Last-Modified:" or "Updated:").

I'd be happy to contribute a PR implementing this feature if it aligns with the plugin's direction.

[attilarepka]

I agree that the underlying issue is valid, and adding a configurable field label makes sense.

I’m leaning toward naming this option *_label rather than *_key, as it more clearly represents display text, though this is not a strong blocker for me.

I’m also open to keeping *_key as proposed, and I’d be happy to review a PR implementing this feature.