Fix Redshift column alteration bug

[SorenSpicknall]

Under current behavior, if you try to copy or upsert a Parsons table to Redshift with alter_table set to True, it'll take the incoming column widths and send them to Redshift as alteration queries. This will fail when a varchar column coming in from the Parsons table exceeds Redshift's maximum column width of 65535.

It's desirable to use the alter_table argument in combination with truncatecolumns to enact a sequence as follows:

1. Incoming Parsons table has values that are too wide for the current column width and too wide for Redshift varchar constraints
2. Parsons resizes the destination columns to take up the maximum allowed width in Redshift, and then
3. Parsons successfully pushes the table to Redshift, truncating the column values that exceed 65535 characters.

As it stands, step 2 fails in this sequence because an invalid column width is sent to Redshift within an alteration query. This caps the allowable length of that alteration query. With this change, copy and upsert calls with truncatecolumns=False would still behave as expected, but calls with that argument set to true and alter_table=True would exhibit the new behavior outlined above.

[shaunagm]

looks good to me (with caveat that I can't do any tests here)