Create UI for selective publishing of changes

This blocks 📌 [PP-2] Create UI for selective discarding of changes Active .

I assume we want to tackle permissions directly here instead of a follow-up. Added permissions requirements here. We can split to a beta-blocker follow-up if it makes more sense.

There's an MR here but it's failing tests, and lots of commits happened on 0.x late last week, so would be good to bring those in (via either merge or rebase).

I have rebased the PR and there were some conflicts also that I resolved. Please review. Thanks!

Tested this manually to see the progress! I noticed few things:

1. For some reason "All changes published!" is visible all the time in the review changes panel
2. There's flickering when opening the review changes panel
3. The "Review changes" button flickers when making changes on a page

Test a this a little, looks good.

It looks like this contains the ability to discard so maybe we can close 📌 [PP-2] Create UI for selective discarding of changes Active as a duplicate?

I closed 📌 [PP-2] Create UI for selective discarding of changes Active as a duplicate of this per #15.

> re: Force reload of the page after discarding a change.
This should only happen if the discard call was successful. Otherwise the user doesn't even see the error message.

@penyaskito spotted a problem, but this mostly needs a review of the many lines of JS this adds :)

I noticed the if I get error in publishing then all the boxes are unchecked.

I tested this by trying publish a code component without publishing the global CSS asset, since #3534989: Error if the user tries to publish Code Component without the Global CSS → this will cause an error

Before I submitted here I had other entities besides the global CSS selected. With just 3 entities it is not a big deal to reselect but if I had many it would be pain to have to reselect, especially if I was only selecting pages after viewing them another browser tab to make sure they were ready publish. If looked at 20 pages and checked the 10 I thought were ready to go I would have to do the process over again if I got this error.

Now that we have 📌 Add field access check on `ApiAutoSaveController::post()` Active and 📌 Add field and entity access check on `ApiAutoSaveController::post()` Active there are more ways to get errors on publish

This could be handled in a follow-up

RE: #20 I think an improvement to UX generally would be to ensure that the selected items are stored in something a bit more long term than just memory - local storage for example. Otherwise a similar issue of trying to review pages one by one and check them off is difficult because each time you navigate to a new page the selection is lost.

I think perhaps a single follow up to address both scenarios would be best to ensure the solution enables both things (maintaining after error, maintaining after page load)

Follow up for persisting the selection as described in #20 and #21 created here ✨ Selective publishing selection should be more persistent (across page loads etc) Active

Tested changes on branch 0.x from ui perspective functinality testing is still pending , found following issue while testing :