fix(code-style): use uv sync if lock file is present

[jorgepiloto]

Fix #926 by using uv pip install or uv sync depending on whether a uv.lock file is present.

[moe-ad]

@jorgepiloto I was wondering if we could extend this to _doc-build-linux, _doc-build-windows, build-wheelhouse, check-vulnerabilities, and tests-pytest. Those are the actions I have noted where something similar to this might be needed (I am not sure if I am missing some others).

Or we could address those in a separate PR if that is what you prefer.

[MaxJPRey]

LGTM.

[da1910]

Suggested change

	uv sync --extra "${extra_targets}"
	uv sync --extra "${extra_targets}" --frozen

If we're using the lock file we need to not regenerate it when we sync

[SMoraisAnsys]

Yeah and we might not want to use dev dependencies so I'd add --no-dev too

[da1910]

Suggested change

	uv sync
	uv sync --frozen

[da1910]

We need to not do this with uv.

[SMoraisAnsys]

Bringing back some activity on this PR :)

I think we have multiple things to discuss before adding lock files:

1. How to allow it's usage ? Default behavior would be the one proposed here but we could also leverage a new input to allow maintainers to activate it / disable it. My main concern here is the interaction between our now pinned actions' dependencies and the lock file defined by users.

2. I think the order of installation should be users lock file first then our requirements (open to discussion)

3. Which actions should be extend with this ability ? At the moment we have some action that can consume requirements files AND uv lock files can be exported in such kind of files so... Maybe to reduce maintenance / action complexity we could avoid adding this ability in such actions and encourage to export ftm ?

4. Should we extend our action to leverage venv everywhere ? That's not the case atm (see build-library for example) and this could impact how we want to interact with the lock file. If nothing is done we can use sync (when a venv is defined) or install when that's not the case.