Fix: Handle view materialization alterations

[axellpadilla]

This commit addresses the following:

• Modifies the create view macro to use alter view when the view already exists, preventing errors during re-materialization and non-dbt grants deletion.
• Updates the view materialization logic to correctly handle scenarios where a table with the same name exists. It now renames the existing table to a backup before creating the view.
• Adds a test case to verify that materializing an existing view updates its definition correctly, including column changes.
• Fixed that the existing relation backup renaming was on a wrong order, upstream core is also that way.

All tests passing.

[axellpadilla]

Hi @cody-scott , did you have any time to review this? Maybe you could authorize some extra hands to make reviews or even maintainers, thing is, on sql server a drop/create view are 2 steps and plenty of system tables modifications, while alter is 1 step and less overhead, this should be a high impact change for big dbt projects (it is for my use cases).