[Feature Request] exhaustive-deps linting rule: allow custom hooks to specify the index of their callback effect

# Background Currently, the `react-hooks/exhaustive-deps` linting rule allows developers to lint custom hooks. E.g.: ``` { "rules": { // ... "react-hooks/exhaustive-deps": ["warn", { "additionalHooks": "(useMyCustomHook|useMyOtherCustomHook)" }] } } ``` While the [official documentation](https://www.npmjs.com/package/eslint-plugin-react-hooks) for this configuration states "We suggest to use this option **very sparingly, if at all**", there are nonetheless certain custom hook cases that necessitate such an approach. Consider the following scenario: (1) a callback needs to hook into an external system (thus requiring an effect), (2) the callback has dependencies on state / props and needs to reexecute when those change, (3) executing that callback can be arbitrarily expensive, so re-executing every render is not an option. # Motivation To meet this challenge, we have two options: (1) treat the callback reference as sufficiently reactive (by this I mean, referentially stable unless a dependency has changed) — in other words, we assume the user of the hook is passing in a callback that was defined via useCallback, with the appropriate dependencies; (2) accept dependencies in the custom hook itself, wrap the function in a `useEvent` / `useEventHandler` style hook for referential stability, apply the dependencies to whatever effect the function is then executed within. If we go with option (1) we have an obvious shortcoming — there's no way to ensure the user is wrapping their callback in useCallback. From personal experience on a large industry project with lots of developers, this is just not a viable option. Option (2) on the other hand meets all our needs, and via the `additionalHooks` config, we can ensure correctness by linting for exhaustive dependencies. # The Problem Great! We've met our challenge with a robust solution and easy to use solution, however...... what if our hook accepts a third, or fourth arg? Well, the [current implementation…