Hcheng/add slice to mutator

[hwmarkcheng]

SUMMARY

Hi team,

We're looking to make a few changes that would allow folks to populate the sql_query_mutator with more useful params. We're open to discussion on the best practices to do so.

These are the three items we're looking to change:

• Change mutate_query_from_config to take in kwargs (Consistent with intended purpose of sql_query_mutator, see this PR)
• Add slice_id to query_obj : As addition context for query_obj. Having slice_id is versatile and can open doors for powerful integrations/automations. We originally wanted to add in the whole slice object for more options, but some integration tests failed since the object cannot be converted to a dictionary. Happy to discuss the best way to do this going forward.
• Add chart_id and dataset_id as default parameters for mutate_query_from_config

Example Usecase, Automated Data Access Requests via Satori:
Context: We use Satori for our data access management.

• Users posts chart link to request access to specific schemas -> DAR team approves request -> We grab chart/dataset id from query -> Integrate with Satori to automatically identify all schemas in the chart and grant the user access to them

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

• Change sql_query_mutator to add kwargs as comments. Note this will be reverted before committing (we don't want to change this)
  • Click view query on any chart in a dashboard. You should now see the chart_id, as well as the dataset_id
  • 

Changed query_obj tests to account for additional parameters:

• model_tests.py
• query_object_test.py

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API