Relationship migrations confuse pk and primary_key

Hello, I think this will be a quick fix.

**Describe the bug**
Running SearchLight.Migrations.create_relationship_migration creates a file named
2022..._create_relationship_table_model1s_model2s.jl

This file contains the lines:
```
import SearchLight.Migrations: create_table, column, columns, pk, add_index, drop_table

function up()
create_table(:model1smodel2s) do
[
primary_key()
column(:model1s_id, :int)
column(:model2s_id, :int)
]
end
```
So it imports pk, but tries to use primary_key.

**Error stacktrace**
```
julia> SearchLight.Migrations.all_up!!()
[ Info: 2022-01-14 11:45:16 SELECT version FROM schema_migrations ORDER BY version DESC
[ Info: 2022-01-14 11:45:16 SELECT version FROM schema_migrations ORDER BY version DESC
┌ Error: 2022-01-14 11:45:16 Failed executing migration CreateRelationshipTableModel1sModel2s up
└ @ SearchLight.Migration ~/.julia/packages/SearchLight/B9d2o/src/Migration.jl:300
ERROR: UndefVarError: primary_key not defined
...
```
**To reproduce**
Should be fairly obvious...

**Expected behavior**
It imports and uses the same function (pk or primary_key), and the relationship table is created.

**Additional context**
```
julia> versioninfo()
Julia Version 1.6.2
Commit 1b93d53fc4 (2021-07-14 15:36 UTC)
Platform Info:
OS: Linux (x86_64-pc-linux-gnu)
CPU: Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-11.0.1 (ORCJIT, skylake)
Environment:
JULIA_REVISE = auto
```

```
(Myproject) pkg> st
Project Myproject v0.1.0
Status `~/projects/Myproject/Project.toml`
[336ed68f] CSV v0.9.11
[c43c736e] Genie v4.9.0
[e115e502] GenieAuthentication v1.1.0
[6d011eab] Inflector v1.0.1
[e6f89c97] LoggingExtras v0.4.7
[739be429] MbedTLS v1.0.3
[0aa819cd] SQLite v1.3.0
[340e8cb6] SearchLight v2.0.1
[21a827c4] SearchLightSQLite v2.0.0
[4acbeb90] Stipple v0.19.3
[30ddb3f0] StippleCharts v0.16.0
[a3c5d34a] StippleUI v0.14.3
[ade2ca70] Dates
[56ddb016] Logging
```

Start with SearchLight.Migrations.create_relationship_migration and inspect the generated relationship migration, especially its import list and primary-key declaration. Reproduce with SearchLight.Migrations.all_up!!() and verify that the generated migration uses a consistently imported function and creates the relationship table without UndefVarError.

Written by the indexing model from the issue text.