feat: add multi-query transaction support to snowflake piece

[valentin-mourtialon]

What does this PR do?

Enhances the Snowflake piece's query execution capabilities by:

• Adding support for executing multiple SQL queries sequentially
• Introducing optional transaction handling (configurable via checkbox)
• Returning detailed results for each executed query
• Maintaining data consistency with automatic rollback on failure when transactions are enabled

[AdamSelene]

The binds are shared across all queries

• does it work if 1 query does not use all the binds? no error?
• does snowflake support named binding params? to avoid any surprise
• using ? seems dangerous, at least :1 :2 etc. should be deterministic - we should at least update the description to nudge towards the best practice

Have you tested a few different scenarios?

If we don't have an easy solution to prevent such mistakes, an alternative would be to have binds per query - it's a bit more complex but totally possible (Property.Array can be more complex)

[AdamSelene]

Re. named params, looks like the answer is no:
https://stackoverflow.com/questions/76814603/how-can-i-use-named-binding-in-nodejs-while-pulling-data-from-snowflake
(not surprising, I had checked last year already)

[valentin-mourtialon]

does it work if 1 query does not use all the binds? no error?

yes

Have you tested a few different scenarios?

Tested combinations:

1. Unused binds
2. All binds used by query number 1
3. Multiple binds in a query
4. Single bind in a query
5. Different query, different bind (Query 1 uses bind 1, Query 2 uses bind 2)
6. Int binds
7. String binds

Did I miss anything?

[valentin-mourtialon]

If we don't have an easy solution to prevent such mistakes, an alternative would be to have binds per query

I find the way it currently works pretty clear. 🤔 I mean, it works as we could naively expect it to work.

I've updated the description btw.

[valentin-mourtialon]

We could probably ask the AP team for advice about this WDYT?