Refactor functions to use SPI instead of heap specific functions

[za-arthur]

Functions cron_unschedule, cron_unschedule_named, LoadCronJobList used heap specific functions to select or modify records which fails if pg_cron tables are created using table access method other than heap.

This PR refactors that functions to use SPI (similar to other places like ScheduleCronJob) instead of direct call of systable_beginscan and simple_heap_delete functions, which are heap specific.

There are few systable_beginscan calls left which are used to scan system tables, but this is intentional.

[za-arthur]

@microsoft-github-policy-service agree

[sfc-gh-mslot]

Any specific concerns with the heao functions or just general consistency?

[za-arthur]

@sfc-gh-mslot thank you for checking the PR and sorry that I didn't include the motivation in the description in the first place.

We encountered the issue with pg_cron on a database where https://github.com/orioledb/orioledb is used and where the GUC config default_table_access_method = orioledb. In that environment tables cron.job, cron.job_run_details created using orioledb TAM. When a user calls job.unschedule it raises an error:

ERROR: attempted to delete invisible tuple

The PR addresses this by replacing heap specific functions (which are used to access non-system tables, system catalog tables are heap tables and default_table_access_method doesn't affect them) with SPI calls.

I understand that there are not much TAM implementations for Postgres out there. But supporting potential future TAMs and orioledb would be a nice improvement.