Allow releasing bound objects via HTTP

[daniel-beck]

Experimental alternative to #663.

I expect time-based expiration to be problematic (#663 (comment)) so this instead allows releasing bound objects when navigating away from the page that registered the proxies.

Pros: Proxies continue to exist until you leave the page.
Cons: Browser involvement needed, a page can accumulate proxies in badly-written code. Probably more.

The current implementation sends one request per proxy, could be collapsed to just one if this approach is deemed preferable.

Testing done

With jenkinsci/jenkins#10631:

1. Script console from Render t:artifactList lazily jenkins#10623 (comment): Empty
2. Navigate to a job config screen
3. Script console: Very much not empty
4. Navigate away via breadcrumbs
5. Script console: Empty again

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[jglick]

Fine it it works.

[jglick]

@POST?

[daniel-beck]

I guess, although I expect this would be replaced anyway due to

The current implementation sends one request per proxy, could be collapsed to just one if this approach is deemed preferable.

[jglick]

I wonder if it would not be better to just deprecate l:renderOnDemand, and all uses of BoundObjectTable other than ProgressiveRendering which already has its own logic for releasing the object when the user navigates away from the page (currently done on the server side simply by checking whether a request has been received recently). The usual uses of l:renderOnDemand are to lazily render config form snippets, for newly instantiated objects, but these could be done more efficiently by creating an l:ajax page tied to the Descriptor since its contents are not sensitive to context. (Just need to make sure it is not used in case where there is already an instance—normally these are rendered eagerly; and to honor DescriptorByNameOwner when constructing URLs, to ensure compatibility with the CloudBees CI Templates plugin.)