Add a README.md and document using :value tokens to avoid prefix and suffix in expressions

Problem/Motivation

The original request: a way to remove the prefix and suffix of a referenced field before the expression is calculated.

When an expression references a numeric field with a token such as [node:field_price], the Token module renders the field through a formatter. The replaced value therefore contains the prefix, the suffix and, depending on the formatter settings, the thousand separator. For a decimal field with prefix $ and suffix kg:

[node:field_price] * 2   becomes   $1234.50 kg * 2

EvalMath cannot parse this. With Suppress Errors on (the default) the field is silently saved as 0, so the problem is easy to miss.

The same happens when one expression field references another expression field, because the 2.x expression field types also have prefix and suffix settings. #3447908 was another case of the same cause: a thousand separator in the token output.

The Token module already provides the raw stored value through the :value property token, and that works today without any code change:

[node:field_price:value] * 2   becomes   1234.5 * 2   =   2469

The module does not document this anywhere. It has no README, the project page has no example expressions, and the only token example in the Expression setting description ([node:field_some_number]{100}) uses the formatted token.

Steps to reproduce

1. Add a Number (decimal) field field_price to a content type, with prefix $ and suffix kg.
2. Add an Expression (decimal) field to the same content type, with the expression [node:field_price] * 2.
3. Create a node with price 1234.5 and save it.
4. The expression field is 0. Turning on Debug Mode shows the token replaced expression as $1234.50 kg * 2.
5. Change the expression to [node:field_price:value] * 2 and save the node again. The expression field is 2469.

Tested on 2.x-dev with Drupal 11 and Token 8.x-1.17. Tokens of referenced entities work the same way, for example [node:field_product:entity:field_price:value].

Proposed resolution

Add a README.md to the module, following the README.md template. Besides the usual sections (requirements, installation, configuration, maintainers), it documents:

• the field types, field settings and the Always Evaluate Expression? display setting;
• the expression syntax: operators, built-in functions, statements separated by ;, user-defined functions;
• tokens and token default values;
• a "Use raw values in tokens" section explaining the :value token, with the example above;
• troubleshooting for a field that is always 0, pointing to Debug Mode and the :value token.

Alternatives considered:

• Integrate the Tamper module. Tamper is a plugin API without a UI of its own, so this would need a per-token configuration UI, config schema and storage for tamper chains in the field settings. Adding it as a hard dependency in field_expression.info.yml would also force every existing site to install it on update. That is a lot of scope and maintenance for a case the :value token already covers. If a real need for transformations beyond this appears, an optional integration (only active when Tamper is enabled, as Debug Mode is with Devel) can be a follow-up issue.
• Strip non-numeric characters from replaced tokens automatically. This is ambiguous: a formatted 1.234,50 or 1,234.50 cannot be turned back into a number reliably without knowing the formatter settings, and a prefix or suffix may itself contain digits. It also cannot be applied to the whole expression, which legitimately contains letters for functions and variables.

Remaining tasks

• Merge request adding README.md.
• Review.

User interface changes

None.

API changes

None.

Data model changes

None.