Render placeholders located in hyperlink URLs

[alranel]

As of today, if you create a hyperlink in your docx template, placeholders such as {{ foo }} are rendered only in the visible text of the hyperlink but are ignored if placed in the destination URL.
With this simple PR, we'll render those templates even in the URL part making it fully customizable.

[xdong99]

Thanks for the PR. I took a local pass through this because rendering relationship targets seems like the right place to fix hyperlink URLs.

What I checked locally on b98ff321d31bdeceff9c4f306374c1b701361afc:

• ..\env\Scripts\python.exe hyperlink.py from tests/ passes once the usual tests/output/ directory exists.
• ..\env\Scripts\python.exe -m flake8 docxtpl tests setup.py --count --max-line-length=127 --show-source --statistics passes.
• I also ran the existing test scripts with the venv interpreter. Nothing looked attributable to this PR; the run did expose the pre-existing test-runner issue where module_execute.py can print a failed child command but still let the suite continue.

One edge case I found: when callers pass a custom jinja_env with custom delimiters, document XML is rendered with that environment, but hyperlink relationship targets are skipped because render_hyperlinks() and the new relationship scan in get_undeclared_template_variables() only look for the default Jinja markers {{, {%, and {#.

Minimal reproduction from the new fixture:

from jinja2 import Environment

env = Environment(variable_start_string="[[", variable_end_string="]]")
# relationship target is [[ foo ]]
# visible document text renders, but word/_rels/document.xml.rels still contains [[ foo ]]

For a relationship-only variable using those delimiters, get_undeclared_template_variables(jinja_env=env) also returns set().

A small way to keep this aligned with the provided environment would be to base the marker check on the active environment, for example using env.variable_start_string, env.block_start_string, and env.comment_start_string, then render/parse with that same env.

With that handled, this looks like a useful feature and the fixture is a good addition.

[arturict]

For placeholders in URLs, could you include a regression case with mixed % and brace chars?

[CAOShurong]

Reviewed the exact head b98ff321d31bdeceff9c4f306374c1b701361afc independently.

• The full direct-script regression suite passed (including the new hyperlink test); the four optional subdocument tests also passed after installing the declared docxcompose extra.
• The new test verifies both the visible hyperlink text and the serialized external relationship target after saving the DOCX, and get_undeclared_template_variables() reports the URL variable as resolved.
• Additional exact-head checks passed for a URL containing multiple variables, query-string ampersands, and a custom Jinja filter; the rendered relationship target was correct.
• flake8 reported 0 findings, git diff --check passed, and an isolated sdist/wheel build produced docxtpl-0.20.2.tar.gz and docxtpl-0.20.2-py3-none-any.whl.

The implementation limits rendering to external hyperlink relationships and preserves the existing custom Jinja environment, while leaving non-hyperlink relationships untouched. This looks focused and correct to me.

OpenAI Codex assisted with the test setup and execution; I reviewed the diff and observed results before approving.