Full OldTable on AlterTableOperation, further comment support

[roji]

Changed AlterTableOperation.OldTable from Annotatable to TableOperation,
and did various fixes throughout to support comment alteration on tables.

Some comment fixes and refactoring.

Fixes #16819
Fixes #16798

• The extended property functions (e.g. sp_addextendedproperty) don't accept NULL for schema - it must always be passed. Am defaulting to the model default and after that to dbo, hopefully that's right.
• Trying to call sp_addextendedproperty or sp_dropextendedproperty twice results in an error (property is already defined), meaning that this comment implementation isn't idempotent. Does it need to be?

[bricelam]

We should probably generate SCHEMA_NAME() in the SQL instead of relying on hard-coding dbo.

[roji]

Apparently can't pass function calls to SQL Server stored procedures, need to define a variable instead?

😖

Declared a variable, which forces us to think about variable scope etc. - take a look at the second commit.

On the way found another bug where we weren't generating column comments in migration C# code for CreateTable...

[bricelam]

(After addressing comments)

[bricelam]

Do we need a variable at all? Can't we just inline SCHEMA_NAME()?

[roji]

You mean inline SCHEMA_NAME() into the stored procedure EXEC call? Apparently that simply isn't supported, only literals and variables (e.g. https://www.sqlservercentral.com/forums/topic/using-functions-as-parameters-in-stored-procedure-calls).

I definitely don't like that extra T-SQL variable, e.g. it forces us to distinguish first GenerateComment call (which declares and sets it) and the others (which don't, since it's also not possible to re-declare or un-declare a variable).

Will hold off on merging this in case you have some better SQL Server trick or something - otherwise let me know and I'll merge.

[bricelam]

(Doh, just saw your comment above about this too)

[bricelam]

I don't have any better ideas