Allow customizing the delay for InstantClick behavior

[davidalejandroaguilar]

Description

This PR adds a configurable delay to the new InstantClick behavior.

The 100 ms default is a nice one. However, some apps might be fine with having no delay and would prefer to prefetch as soon as possible, so let's provide sharp knives.

Configuration

• Via a data-turbo-prefetch-delay attribute on the <a> element.
• Via a turbo-prefetch-delay meta tag.

Both can be set to any numerical value, or to "0" for no delay. Note that the latter means that setTimeout won't be used at all, so it will be an instant prefetch.

Notes
I also thought about using "false" instead of "0" for no delay, let me know if that or something else is preferred.

[kevinmcconnell]

@davidalejandroaguilar what would be a use case for someone needing to change the prefetch delay? Do you think there will be cases where the difference is quite noticeable, or the default won't provide a good experience?

I think it's generally good if we can keep Turbo's API simple and small, by only adding attributes/tags that many people are likely to need. If a customisation is not in high demand, it might be better to keep it out of that API. (Which is not to say there couldn't still be a way to affect it in code, if necessary.)

Perhaps this is one of those common needs! But I was struggling to think of a concrete example of needing it, so was curious if you had more context about why the setting needs to be exposed. Thanks!

[afcapel]

I agree with @kevinmcconnell. I'd like to see some practical cases where we need this before expanding the public API.

Another thing to note is that we may add InstaClick for keyboard navigation, but that could need different timing. It'd be useful to know what we're going to do with the keyboard events, and if we need different delays for different events, before committing to an API for this.