Allow per-project custom commit types

[javier-godoy]

Problem

Section 1 of the spec defines a fixed list of commit types with "Must be one of the following", leaving no room for domain-specific types. This is intentionally conservative, but it creates a friction point for projects whose domain has commit categories that map poorly to any of the built-in types.

The Conventional Commits specification itself explicitly permits types beyond feat and fix:

"Types other than feat and fix MAY be used in your commit messages."
"Additional types are not mandated by the Conventional Commits specification."

The FC spec already applies a per-project model for scopes (Section 2: "The granularity of scopes and their allowed values are defined on a per-project basis"). Extending the same model to types is a natural and consistent evolution.

Suggestion

In "Type" section:

-Required. Must be one of the following:
+Required. The following types are defined. Additional types may be introduced on a per-project basis:

At the end of "Type" section:

+Additional types MAY be defined on a per-project basis when none of the above
+types adequately describes the change. Custom types must be documented in the
+project's contributing guide, including their intended meaning and the semantic
+versioning increment they correlate with (if any).
+
 An **exclamation mark** `!` following the **type** (and **scope**, if present)

In FAQ section:

+#### When is a custom type appropriate?
+
+A custom type is appropriate only when the change is semantically distinct from
+all built-in types and that distinction is meaningful enough to warrant a
+dedicated label in the project's history. Before introducing a custom type,
+verify that `chore` (or another existing type) does not already cover the
+intent. Custom types must be documented per project.