[17.0][OU-FIX] website_sale: drop stale payment_footer template with its inherit closure

[eantones]

Odoo 17 removed the payment_footer template from website_sale (payment page redesign), but on databases coming from 16.0 the record survives the upgrade whenever another view inherits it.

The end-of-pass obsolete-record cleanup deletes records one statement at a time, so ir_ui_view_inherit_id_fkey blocks the template's DELETE when an inheriting view (website COW copies included) is scheduled for deletion later in the same pass. The delete fails as a logged "bad query", and the stale 16.0 markup survives into the 17.0 database.

Fix in the migration itself: a post-zz script for website_sale 17.0.1.1 that deletes the template together with its whole inherit closure in ONE recursive-CTE statement per table (ir.model.data first, then ir_ui_view). FK checks run at statement end, which makes the closure delete atomic. Keyed on the stable view key, so it is idempotent and immune to record-id drift between dumps (observed: the same view landed on id 6694 in one dump and 6740 in a fresh one).

Validated on a real 16.0 → 17.0 OpenUpgrade run (production-size database, website in use): the script deleted the template plus one inheriting child (2 ir.model.data rows + 2 ir_ui_view rows) and the "bad query" line disappeared from the hop log; the 17.0 database ends with no website_sale.payment_footer leftovers.

[eantones]

Superseded by the core fix (nuobit/odoo#9 for 17.0, nuobit/odoo#10 for 18.0).

This PR cleaned up the orphaned website_sale.payment_footer after the fact. The root cause is in core: View.unlink() cascades inherit_children_ids when _force_unlink is set, but reads them with active_test on, so the inactive payment_sale_note child is skipped and its inherit_id RESTRICT FK rejects the parent's DELETE. Fixing the cascade means the parent is deleted cleanly at the hop and there is no orphan left to clean.