Use target project's Proj object when calling save_record hook

[ChemiKyle]

Also use target project's target record as record param when calling save_record hook

These changes are motivated to ensure interoperability with the Auto DAGs Module. I'm calling them out here so you can correct any assumptions that wouldn't apply in a general sense.

---

$target_record_id

$target_record_id is needed to ensure that $data is pulled for the correct record:

https://github.com/vanderbilt-redcap/auto-dags-module/blob/7f2c98d89a010775ab5ce526a05c5d4ef52f6d21/AutoDAGsExternalModule.php#L25

IMO, the old $_GET['id'] = $dataToPipe[$targetProject->table_pk] setting doesn't actually make much sense with how $dataToPipe is formatted anyway since it would always be null

$dataToPipe = [
  $target_record_id => [
    $first_event_id => [
      "field_name" => "field_value",
      ...
    ]
  ]
]

---

Emulation of target project's $Proj object

$Proj needs to emulate the target project to ensure REDCap::getGroupNames enumerates the groups in the target project. Without emulating being in the target project, this call returns whatever the ARG module's project's DAGs are, usually resulting in duplication of DAGs in the target project.

https://github.com/vanderbilt-redcap/auto-dags-module/blob/7f2c98d89a010775ab5ce526a05c5d4ef52f6d21/AutoDAGsExternalModule.php#L55

This should rectify any issues where the target project's modules operate on the $Proj object, though I'm not sure how y'all feel about overriding that global object if only temporarily; on that note, my only trepidation is that since the try-catch block doesn't catch error spawned by the target project's modules, the $Proj object won't be reset to $oldProj (which shouldn't matter too much since the rest of the ARG module shouldn't execute, and the problem would be rooted in the module whose redcap_save_record hook was called anyway).