intercom-rails gem fix Turbo / Turbolinks

Hello,

there is a bug related to Turbo / Turbolinks within gem `intercom-rails` several years. I prepared fix, which I hope to fix it for good. But unfortunately there is a restriction for create new pull requests on GitHub.

So please check Issue https://github.com/intercom/intercom-rails/issues/336#issuecomment-5491505415 with my comment and suggested changes 😛  

master...luk4s:intercom-rails:301_fix_turbolinks

This issue I thinks its related to #244 and #301, also there is #215 (but outdated with conflict) with similar topic.

Summary:

Javascript already listens for turbo:visit, turbo:before-cache and
turbo:load, along with their turbolinks: equivalents, so ordinary Turbo Drive and
Turbolinks 5 navigations need no configuration. Three cases fall outside those events:

• Form submissions that fail validation. Turbo replaces the body for a 422 Unprocessable Entity response without announcing a visit, so the Messenger is never
  told that the elements it injected have been removed. Its detached iframes then raise
  Cannot read property 'document' of null. The shim synthesises the visit around the
  render instead.
• Turbo 8 morphing refreshes. Morphing removes any element missing from the server
  response, which is everything the Messenger injected. When Turbo announces a morph,
  the shim marks those elements data-turbo-permanent so morphing leaves them alone.
• Turbolinks 2.x and 3.x. These predate the turbolinks: events, so the shim
  bridges their page:before-unload and page:load equivalents.

Nothing in the shim runs until Turbo or Turbolinks dispatches an event, so it needs no
configuration and is inert in applications that use neither. It is part of the same script
tag as the Intercom snippet.