fix: fix unstable tag generation for composite indexes with different column orders

[ucpr]

• Do only one thing
• Non breaking API changes
• Tested

What did this pull request do?

Fix unstable tag generation for composite indexes with different column orders.

User Case Description

When multiple composite indexes exist on the same columns but in different orders, the generated code may have unstable tag output.

Example:

CREATE TABLE users (
    id INT PRIMARY KEY,
    email VARCHAR(255),
    name VARCHAR(255),

    -- composite indexes with different column orders
    INDEX idx_email_name (email, name),
    INDEX idx_name_email (name, email)
);

With a schema like the above, the generated tags can vary between runs:

// First run
Email string `gorm:"index:idx_email_name,priority:1;index:idx_name_email,priority:2"`

// Second run (order may differ)
Email string `gorm:"index:idx_name_email,priority:2;index:idx_email_name,priority:1"`

[qqxhb]

Looking at this example, isn't the index created unreasonably?

[ucpr]

@qqxhb

Thank you for the feedback! You're absolutely right that this index pattern might not be ideal from a design perspective.

However, I believe the generator should handle this case properly because:

1. Database specifications allow it: MySQL/PostgreSQL and other databases explicitly allow creating multiple composite indexes on the same columns with different orders. Since it's permitted by the database specification, the generator should produce deterministic output for such cases.

2. Legacy project reality: While I agree this index design is problematic, in the legacy project I'm working on, such indexes unfortunately already exist in production. 😢

The current non-deterministic tag generation causes unnecessary git diffs and makes it difficult to track actual changes. This PR ensures stable output regardless of the index design choices, which helps maintain cleaner version control history.