remove(sh_sql): Remove adding columns to existing database table

[Histalek]

Before this change it was possible to add columns to an existing database table through the sql.CreateSqlTable() function.

This is a troublesome and undocumented(!) functionality which should not exist going further.
Troublesome as once a column is added there is no way back. This whole functionality also sways from the CreateSqlTable expectation as running a CREATE TABLE statement on an existing sqlite table fails normally. (In our case we used this function to ensure a table exists, hence we now return true if the table already exists)

sql.CreateSqlTable is now also "soft" deprecated through our code annoations and therefore in our api-docs.
Handling database table definitions should be done through migrations from now on.

"Hard" deprecation (ErrorNoHalt on function call) should follow once we have migrated our codebase to use migrations to prevent spamming of deprecation messages.

Additionally this partially fixes (screw you github...) #1418 as one of the offending pragma statements is removed.

A few notes:

• i'm not super sure on the Dev messages, maybe those could be improved/changed
• i've gone with the "soft" deprecation route so this could be merged for v0.13.0, but it is definitely not required.

[ZenBre4ker]

Generally fine to deprecate it. But I dont like it, that there is no alternative besife writing sql code yourself. I'd like to keep the create sql table function and rather limit it to migrations.

[TimGoll]

Was this functionality used somewhere in our codebase? It is really weird and unexpected behaviour. I therefore agree with your change here. Not sure if it should be Dev 1 or 2, but I think it is fine that way!

[ZenBre4ker]

Was this functionality used somewhere in our codebase? It is really weird and unexpected behaviour. I therefore agree with your change here. Not sure if it should be Dev 1 or 2, but I think it is fine that way!

Everytime we changed the savingKeys for the shop for example, this was used.

[TimGoll]

Was this functionality used somewhere in our codebase? It is really weird and unexpected behaviour. I therefore agree with your change here. Not sure if it should be Dev 1 or 2, but I think it is fine that way!

Everytime we changed the savingKeys for the shop for example, this was used.

I'm a bit OOTL on all the recent database/migration changes. So was this changed already? or is this PR breaking things?

[ZenBre4ker]

Lets explain it like this:
For example we added in version 0.12.? the DeathOnDropOverride for the shopeditor.
There we added this "item" to the savingKeys as additional Column.
When Sql.CreateSqlTable is called, it checks if the stored Keys are equivalent to the ones that shall be applied.
If that is not the case, we just add them.
Therefore the table is changed.

With this PR this will be forbidden or just not used anymore.
If the savingKeys change, they will not update the sql table anymore and will therefore result in missing data.

[TimGoll]

Ok, I get it now, thank you!

[Histalek]

Given that this would break users that have played ttt2 before v0.12.0 but haven't started v0.12.0 or above yet i'm not exactly keen on merging this without having the affected tables be fully controlled by migrations.
Holding off on merging this seems like the best idea for now.

[TimGoll]

Given that this would break users that have played ttt2 before v0.12.0 but haven't started v0.12.0 or above yet i'm not exactly keen on merging this without having the affected tables be fully controlled by migrations. Holding off on merging this seems like the best idea for now.

Migrations are done now, in case you want to finish this PR!