Update documentation for 1.21 actions

[sillyguodong]

As title.
Close #26309
Related to #24724, #24806

[GiteaBot]

@sillyguodong please fix the merge conflicts. 🍵

[delvh]

Suggested change

	After Gitea 1.21 released, you can change labels by modfiying `container.labels` in configuration file (if you don't have a configuration file, please refer to [configuration tutorials](#configuration)), and runner will declare the new labels which you defined in configuration file after executing `./act_runner daemon --config config.yaml`.
	Starting with Gitea 1.21, you can change labels by modifying `container.labels` in the runner configuration file (if you don't have a configuration file, please refer to [configuration tutorials](#configuration)).
	The runner will use these new labels as soon as you restart it, i.e., by calling `./act_runner daemon --config config.yaml`.

[delvh]

Suggested change

	You can create configuration varibales with user, organization, repository level. And the level of the variable depends on which setting panel you created in.
	You can create configuration variables on the user, organization, and repository level.
	The level of the variable depends on where you created it.

[delvh]

Suggested change

	- Varibale names can only contain alphanumeric characters (`[a-z]`, `[A-Z]`, `[0-9]`) or underscores (`_`). Spaces are not allowed.
	- Varibale names must not start with the `GITHUB_` and `GITEA_` prefix.
	- Varibale names must not start with a number.
	- Varibale names are not case-sensitive.
	- Varibale names must be unique at the level they are created at.
	- Varibale names must not be 'CI'.
	- Variable names can only contain alphanumeric characters (`[a-z]`, `[A-Z]`, `[0-9]`) or underscores (`_`). Spaces are not allowed.
	- Variable names must not start with the `GITHUB_` and `GITEA_` prefix.
	- Variable names must not start with a number.
	- Variable names are case-insensitive.
	- Variable names must be unique at the level they are created at.
	- Variable names must not be `CI`.

[delvh]

Suggested change

	After creating configuration varibales, they will be automatically filled in the `vars` context. They are available to you with expression like `{{ vars.VARIABLE_NAME }}` in workflow.
	After creating configuration variables, they will be automatically filled in the `vars` context. They can be accessed through expressions like `{{ vars.VARIABLE_NAME }}` in the workflow.

[delvh]

Suggested change

	If a variable with the same name exists at multiple levels, the variable at the lowest level takes precedence(the level of organization and user is higher than repository's).
	For example, if an organization-level variable has the same name as a repository-level variable, then the repository-level variable takes precedence.
	If a variable with the same name exists at multiple levels, the variable at the lowest level takes precedence:
	A repository variable will always be chosen over an organization/user variable.

[delvh]

Oh.

[sillyguodong]

I will create a new PR to update😂