Added support for MATCH syntax and unified column option ForeignKey

[LucaCappelletti94]

This PR adds support for the SQL standard MATCH [FULL | PARTIAL | SIMPLE] syntax for foreign key constraints.

Changes

• Extended keywords to include PARTIAL and SIMPLE
• New MatchKind enum with Full, Partial, and Simple variants
• Parser support for MATCH syntax in both column-level and table-level foreign key constraints
• Refactored ColumnOption::ForeignKey to use ForeignKeyConstraint struct, eliminating code duplication
• Added opportune tests
• Added opportune documentation for newly supported syntax

Examples

-- Column-level constraint
CREATE TABLE orders (
    id INT REFERENCES customers(id) MATCH FULL ON DELETE CASCADE
);

-- Table-level constraint  
CREATE TABLE orders (
    customer_id INT,
    FOREIGN KEY (customer_id) REFERENCES customers(id) MATCH SIMPLE
);

Closes issue #2061 and works towards closing issue #2059

[iffyio]

not sure what this change implies, it looks like we'd be storing the column name twice in the AST node which doesn't seem ideal?

[LucaCappelletti94]

It is needed to standardize ForeignKeyConstraint and avoid having a duplicated struct to represent the same type of concept. I could possibly leave the columns vector of the ForeignKeyConstraint empty, but when I use that struct in code that works on top of the AST it is quite useful to have the column ident defined there, and not have to handle the case of a special ForeignKeyConstraint.

[LucaCappelletti94]

You will note that it is the same change needed for PR #2064, which I did separately but the goal is identical - to standardize the structs used to represent constraints in the columns and table.

[iffyio]

I see, the goal of the AST is to represent the syntax as closely as possible so that I don't think that storing the column name in another node in the tree than where it was found seems reasonable. haven't looked closely at the different foreign key constraint variants but I would assume that if both variants show up in different parts of the syntax then its not unreasonable that they are represented differently

[LucaCappelletti94]

I agree with that, but this philosophy of using the most strictly compatible AST nodes in the different parts of the tree has already been broken several times to reduce code duplication.

Here I am quite unsure whether the most appropriate solution would be to:

1. use the table constraint struct and duplicate the column ident
2. use the table constraint struct and leave its columns attribute empty
3. use a new struct to strictly represent the column option for this constraint variant (for the same reasons of having structs instead of struct variants)

I would personally be inclined with 1 or 2, but I understand the duplication concerns of 1. Btw, is there any particular reason for the current clone-based approach for idents instead of a copy and lifetime based one?

Lmk your opinion regarding how do you feel best proceeding.

[LucaCappelletti94]

I went for solution number (2), let me know whether you agree with it.