feat: make legacy consent management fields source specific

[saikumarrs]

Description of the change

As we plan to support generic consent management for client-side SDKs, to make the backward compatibility feasible, we must make the legacy fields source-specific instead of defaultConfig.

This PR addresses it for all the destinations. Extended the Ketch consent management for all the destinations.
Also, test data has been created for both the consent management fields.

Apologies for the huge PR.

Other changes:

• Upgrade to Node v20.
• Updated labels of consent management fields to specify "IDs".
• deployment script
  • Added request timeout
  • Formatted JSON output
  • "na" changed to "N/A"
  • Stopped printing username to avoid its exposure
  • Beautified output formatting

Checklists

Development

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• The code changed/added as part of this pull request has been covered with tests
• All tests related to the changed code pass in development
• I have executed schemaGenerator tests and updated schema if needed

Code review

• This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached
• Changes have been reviewed by at least one other engineer
• Issue from task tracker has a link to this pull request

[devops-github-rudderstack]

This PR is considered to be stale. It has been open for 20 days with no further activity thus it is going to be closed in 7 days. To avoid such a case please consider removing the stale label manually or add a comment to the PR.

[devops-github-rudderstack]

This PR is considered to be stale. It has been open for 20 days with no further activity thus it is going to be closed in 7 days. To avoid such a case please consider removing the stale label manually or add a comment to the PR.

[devops-github-rudderstack]

This PR is considered to be stale. It has been open for 20 days with no further activity thus it is going to be closed in 7 days. To avoid such a case please consider removing the stale label manually or add a comment to the PR.

[devops-github-rudderstack]

This PR is considered to be stale. It has been open for 20 days with no further activity thus it is going to be closed in 7 days. To avoid such a case please consider removing the stale label manually or add a comment to the PR.

[devops-github-rudderstack]

This PR is considered to be stale. It has been open for 20 days with no further activity thus it is going to be closed in 7 days. To avoid such a case please consider removing the stale label manually or add a comment to the PR.

[devops-github-rudderstack]

This PR is considered to be stale. It has been open for 20 days with no further activity thus it is going to be closed in 7 days. To avoid such a case please consider removing the stale label manually or add a comment to the PR.

[devops-github-rudderstack]

This PR is considered to be stale. It has been open for 20 days with no further activity thus it is going to be closed in 7 days. To avoid such a case please consider removing the stale label manually or add a comment to the PR.

[saikumarrs]

Closing this in favour of #1651