Automatically suggest adding the webhook and provide instructions on how to add it when reacting to commands via scraping

[yaahc]

This was suggested by @anp when we were talking about rfcbot and how to create a dashboard ranking issues with the "feature-request" tag based on the emoji reactions on the top comment. As he explained it, RFC bot currently supports two methods of receiving commands, via a webhook or by scraping. When commands are received via the webhook they are reacted to instantly, where as the scraping is done very infrequently. We both had the immediate reaction that it might have been a bad idea to even support the scraping option in the first place because it encourages people to leave the webhook unconfigured, where as if we had only had the webhook option people would be more accustomed to setting it up.

As it stands, I doubt its a good idea to just whole-sale remove the scraping option and break rfcbot for repos that have been relying on it for ages now. However, I think it would be a good idea to start creating comments or issues on such repos pointing to the docs on how to setup the webhook and possibly plan for an eventual deprecation and removal of the scraping API.

[anp]

IIRC, the reason for having both scraping and webhooks is because rfcbot's predecessor rusty-dash was running for a while and proving its usefulness before a couple things happened:

1. we added rfcbot to rusty-dash and people cared about interaction latency, not just data latency
2. adding more repos to the configuration started hitting github rate limits when scraping and made us reduce the frequency of the scrape

Honestly, we probably should have turned down the scraping at that point, but perfect hindsight etc etc. I get pinged once every month or two asking why rfcbot is responding slowly and its always on a repo that's newer and hasn't been configured yet -- maybe having rfcbot seem like it "just work"s on rust-lang/ repos isn't so great when the way it works is a poor experience.