Use HTTPS links for Google domains in docs

docs/writing_clang_plugins.md

 # Don't write a clang plugin
 
 [TOC]
 
 Make sure you really want to write a clang plugin.
 
 *   The clang plugin api is not stable. If you write a plugin, _you_ are
     responsible for making sure it's updated when we update clang.
 *   If you're adding a generally useful warning, it should be added to upstream
     clang, not to a plugin.
 *   You should not use a clang plugin to do things that can be done in a
     PRESUBMIT check (e.g. checking that the headers in a file are sorted).
 
 Valid reasons for writing a plugin are for example:
 
 *   You want to add a chromium-specific error message.
 *   You want to write an automatic code rewriter.
 
 In both cases, please inform
-[clang@chromium.org](http://groups.google.com/a/chromium.org/group/clang/topics)
+[clang@chromium.org](https://groups.google.com/a/chromium.org/group/clang/topics)
 of your plans before you pursue them.
 
 # Having said that
 
 clang currently has minimal documentation on its plugin interface; it's mostly
 doxygen annotations in the source. This is an attempt to be half map to the
 header files/half tutorial.
 
 # Building your plugin
 
@@ skipping 120 matching lines @@
 If you want to add additional checks to the existing plugins, be sure to add the
 new diagnostic behind a flag (there are several examples of this in the plugins
 already). The reason for this is that the plugin is bundled with clang, and the
 new check will get deployed with the next clang roll. If your check fires, then
 the next clang roll would now be blocked on cleaning up the whole codebase for
 your check – and even if the check doesn't fire at the moment, maybe that
 regresses until the next clang roll happens. If your new check is behind a flag,
 then the clang roll can happen first, and you can add the flag to enable your
 check after that, and then turn on the check everywhere once you know that the
 codebase is clean.