Add resource file support to custom parser API

Context

Born from this discussion on Slack: https://robotframework.slack.com/archives/C015KB1QSDN/p1775116818448659

Robot includes the Parser API:

Robot Framework supports external parsers that can handle custom data formats or even override Robot Framework's own parser.

Recently, I tried to use this API to centrally replace the import to a library. In doing so, I found out that the parser API only works for suite files (.robot files with tests/tasks) and init files (__init__.robot files). Any other filetype is unsupported by the Parser API. This includes:

• Resource files (.robot/.resource files without tests/tasks)
• Variable files (.json/.py/.yaml, ...)
• Library files (.py)

Goal

Extend the parser API to also allow control over the following filetypes:

• Resource files
• Variable files Already controllable through Python logic using a .py file with get_variables function. Because of this, I see no need right now to add support for this to the Parser API. If someone disagrees, please open a separate issue for this.
• Library files Already controllable through Python logic because these are Python files by definition. Because of this, I see no need right now to add support for this to the Parser API. If someone disagrees, please open a separate issue for this.

Possible design

The current parser API is implemented with a parse and parse_init method/function. See user guide for details. The parse function allows you to change suite files. The parse_init function allows you to change __init__.robot files.

Add a new function/method to the Parser API: parse_resource. Example:

from robot.running.resourcemodel import ResourceFile

class RobotPreParser:
    def parse_resource(self, source: Path) -> ResourceFile:
        resource = ResourceFile.from_file_system(source)
        # Do something interesting
        return resource

This would allow full control over both the raw and the parsed resource file before Robot does anything else with it. This approach builds out the existing parser API. This should be a non-breaking change.

Optionally, parse can be renamed to parse_suite. This would make it clear what the function applies to. This is a breaking change. A soft deprecation is possible here: Rename to parse_suite, make parse an alias for parse_suite, deprecate parse in subsequent major version(s). Renaming the parse function can be a separate issue.