Add composite foreign key

[naftalmm]

This PR closes #511 (and its duplicate #1234).

From the DSL point of view, there was added a new method for the Table class (foreignKey), supposed to be called in init
block.

It has two overloads, allowing two ways for defining composite foreign keys:

1. listing pairs of the column to column references (set of referenced columns must form an explicit unique constraint)
2. listing columns set referencing primary key:

val TableC = object : Table("TableB") {
    val idA1 = integer("id_a1")
    val idA2 = integer("id_a2")
    val idB1 = integer("id_b1")
    val idB2 = integer("id_b2")

    init {
        foreignKey(idA1 to TableA.idA1, idA2 to TableA.idA2)
        foreignKey(idB1, idB2, target = TableB.primaryKey) // foreignKey(idB1 to TableB.idB1, idB2 to TableB.idB2) is also possible
    }
}

val TableA = object : Table("TableA") {
    val idA1 = integer("id_a1")
    val idA2 = integer("id_a2")

    init {
        uniqueIndex(idA1, idA2)
    }
}
val TableB = object : Table("TableB") {
    val idB1 = integer("id_b1")
    val idB2 = integer("id_b2")
    override val primaryKey = PrimaryKey(idB1, idB2)
}

[Tapac]

Thank you very much for fixing issue requested so many time!
I kept a few comments to fix but I think they are all more like a minor fixes

[Tapac]

I guess that check that size of from and target.columns is the same. Also, maybe it's worth to check column types?

[naftalmm]

Added check for collections sizes. But columns type check is rather tricky - naive type equality check (from.columnType == target.columnType) will be too restrictive because SQL (at least postgreSQL) allows:

• referencing from INT to SERIAL
• referencing from INT NOT NULL to INT NULL (and vice versa!)
• referencing from VARCHAR(50) to VARCHAR(100) (and vice versa!)
• referencing from INT/SMALLINT to BIGINT (and vice versa!)

And definitely, this list is not exhaustive - it's just my experiments in sqlfiddle

So, the new method IColumnType.isCompatibleWith(other: IColumnType) : Boolean needs to be added first to make this check possible. But it looks like a big research task, at least I couldn't quickly find any docs about types compatibility (which type could be referenced to which in foreign key constraint) for any of SQL dialects.

[Tapac]

Yes, it is.