Add ability for customers to filter out rows changed for trigger

From https://github.com/Azure/azure-functions-sql-extension/discussions/840

>I've written an Azure function using the SQL trigger to process records that have been inserted into a table. When I am finished with the processing, I need to update the record that was processed to indicate it was successfully processed. Currently I am using a DbContext and calling ExecuteSqlInterpolated to update the underlying record from within the function, using the ID of the record that was processed via the triggered function. However, this results in another change to the DB that causes the trigger to fire again. When the function runs, I can filter the changes list to only include inserts, like this: changes.Any(m => m.Operation == SqlChangeOperation.Insert) That way I skip processing for those, but it is an unnecessary call to the function nonetheless. Is there a way to ignore updates (or inserts or delete for that matter) that are made inside the function, either by not tracking them, or using CHANGE_TRACKING_CONTEXT in the UPDATE statement and ignoring that context in the queries in this library's class SqlTableChangeMonitor ? This would be similar to what's described here https://www.mssqltips.com/sqlservertip/6521/sync-sql-server-change-tracking-tables-without-changing-data/

The general idea here is to give customers a way to easily filter out rows from triggering the function. A couple ways we could do that :

1. Have a hardcoded SYS_CHANGE_CONTEXT that we ignore when fetching changes. Customers could then use this in their own code to set the context when making changes they want to be ignored
2. Allow customers to pass in their own values of SYS_CHANGE_CONTEXT to ignore

In addition to this, we should probably also make output bindings able to have a context set when making the upsertions so that people can easily chain together trigger & output bindings without running into the same problem above.

Start by reading the SQL trigger change-monitoring path, especially SqlTableChangeMonitor, and then inspect the output-binding path for database upserts. Done means customers can configure which change contexts are ignored and output bindings can set a context for their writes, with the resulting trigger behavior verified.

Written by the indexing model from the issue text.