Rethink token scanning

[brianamarie]

Based on @gregose's feedback in #81:

Another item would be to have someone commit an access token and have it revoked with the credential scanning feature... but thats a bit tricky to implement in a safe way. I'm not sure what we could do there. Maybe a dummy token we could scan for? @ptoomey3 (not part of this org yet) may have some ideas.

This is something we started with, but took out. The possible benefits would be:

• Raise awareness of token scanning as a feature
• Let people know they shouldn't be committing tokens

The reasons we decided to take them out are:

• For the flow to happen as a step, we would actually ask them to commit a token, which ultimately isn't a behavior we want users to do. In general, if a user shouldn't do it in every day life, we don't want them to practice it during a course
• When the token is added to a repository, the user who added the token isn't notified at all. The notifications (from what I understand) all take place on the other end, so that the service provider who owns that token will be the one notified, and the token can be revoked. To a user, it would be anticlimactic and we wouldn't see anything happen in reaction to that commit immediately

This is definitely still not a perfect case, because I think we could do a better job of talking about token scanning and tokens in general. Maybe some different verbage around the .gitignore? Or, if I've misunderstood how the alerts would be sent when a token is committed, maybe we should rethink this completely? I still worry about instructing a user to commit a dummy token, but we could have the bot do it, and have the user fix it.