feat(licenses): support REUSE specification in licenses (#38720)

extends the current license detection to support two modes:
- legacy which is using classification and was expanded to handle more
paths (extensions, different spelling or GNU copying file)
- REUSE which avoids classification by relying on the spec dictating
that license must be named as SPDX-ID.extension. Newly created
repositories will default to REUSE based paths

Use of styles at the same time is not allowed by design.

Extends the UI to show all the detected licenses and paths to them,
deduplicating them per SPDX-ID in database as is in github

closes: https://github.com/go-gitea/gitea/issues/28672


---------

Assisted-By: omp:glm5.2
Assisted-By: omp:mimo-v2.5-pro
Assisted-By: omp:mimimax-m3
Assisted-By: omp:kimi-k3
Assisted-By: omp:deepseek-v4-flash
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>

docs/guidelines-backend.md

@@ -83,6 +83,24 @@ be touched by pull requests whose sole purpose is updating dependencies. Run
 Any `go.mod` / `go.sum` update must be justified in the PR description and must be
 verified by reviewers and the merger to reference an existing upstream commit.
 
+## Golang HTML template
+
+Gitea uses Go's built-in HTML template engine which is dynamically & weakly typed.
+To make template code maintainable:
+
+- Go code should take over complex logic and prepare template data as much as possible, templates only render the data.
+- Prefer struct types provided by Go code instead of map types for template data.
+- Avoid using single world names for non-local variables.
+- Avoid passing `"root" $` or `"." .` to sub-templates, instead pass the specific data needed by the sub-template.
+- Use explicit variable names instead of `.` to access data: ``{{range $item := $.TargetItems}}{{ $item.Name }}{{end}}``
+- Use Go code to implement render helpers if the render logic is too complex.
+
+Using a modern and statically & strongly typed template engine to replace Golang HTML template might be good,
+but the challenge is huge, the requisites are:
+
+- A working and maintainable proof-of-concept for the most complex templates (like "PR View" and "PR Diff").
+- A firm commitment of sufficient engineering resources.
+
 ## API v1
 
 The API is documented with [Swagger](https://gitea.com/api/swagger) and is modelled
@@ -120,7 +138,7 @@ In general, choose HTTP methods as follows:
 - **POST** creates a new object (e.g. a user) and returns **201 Created** with the
   created object.
 - **PUT** adds or assigns an existing object (e.g. a user to a team) and returns
-  **204 No Content** with no body.
+  **204 No Content** with no response body.
 - **PATCH** edits an existing object and returns the changed object with **200 OK**.
 - **DELETE** removes an object and returns **204 No Content** with no body.