Detecting of the preview mode breaks AJAX and View Area

Problem/Motivation

In the issue ✨ Allow usage of VEFS in preview mode Fixed , support for the preview mode was added. But this change introduces an issue with broken AJAX, because when Views renders the AJAX response, it sets the preview=TRUE

The same is with the "View" area plugin (when we insert a view inside a view by the "View area" plugin, the Header or Footer - it uses the preview=TRUE mode too.

In the result, on the real page (not in the Views edit page) we have the wrong ID for the form selector, like this:

<div class="views-filters-summary views-filters-summary--use-ajax" data-exposed-form-id="views-ui-preview-form" data-once="views-filters-summary"><span class="prefix">

Steps to reproduce

Case 1:
1. Create a view.
2. Enable AJAX mode in the view.
3. Choose some exposed options.
4. Click on the "Reset" link or on any "Remove filter" link.

Actual result: It doesn't work, showing an error: Uncaught TypeError: exposedForm is null
Expected result: It should work.

Case 2:
1. Create a View with a Page display with some exposed filters.
2. Create a "Block" display with another exposed filters, save the Views entity.
3. Insert the created block into the "Footer" section of the Page display using the "Views area" plugin.
3. Choose some exposed options in the embedded view block, submit, see that the Summary items appeared.
4. Click on the "Reset" link or on any "Remove filter" link on the embedded views block.

Actual result: It doesn't work, showing an error: Uncaught TypeError: exposedForm is null
Expected result: It should work.

Proposed resolution

Seems we have to make additional checks to ensure that the current preview mode is related to the Views edit page, not to the real website pages.

Remaining tasks

User interface changes

API changes

Data model changes