Stale TODO/Proto-rules

A number of entries in the To-do: Unclassified proto-rules are addressed in the main text:

• "Avoid implicit conversions"
  addressed by C.164: Avoid conversion operators and C.46: By default, declare single-argument constructors explicit
• "Always initialize variables, use initialization lists for member variables."
  addressed by ES.20: Always initialize an object and C.49: Prefer initialization to assignment in constructors
• "Anyone writing a public interface which takes or returns void* should have their toes set on fire"
  addressed by I.4: Make interfaces precisely and strongly typed
• "Use const-ness wherever possible: member functions, variables and (yippee) const_iterators"
  addressed by Con.1: By default, make objects immutable, Con.2: By default, make member functions const and the rest of the Con section, although const_iterators probably need a new Con rule.
• "Use auto"
  addressed by ES.11: Use auto to avoid redundant repetition of type names
• "(size) vs. {initializers} vs. {Extent{size}}"
  would be addressed by C.105: Give a constructor and Extent constructor when it's written (a stub rule is better than a line in the TODO list)
• "Never pass a pointer down the call stack"
  possibly addressed by F.43: Never (directly or indirectly) return a pointer or a reference to a local object? A little unclear given that lifetime safety is missing.
• "should virtual calls be banned from ctors/dtors in your guidelines?"
  addressed by C.82: Don't call virtual functions in constructors and destructors
• "Use RAII lock guards"
  addressed by CP.20: Use RAII, never plain lock()/unlock()
• "Join your threads ... could support library provide a RAII wrapper for std::thread"
  addressed by CP.25: Prefer gsl::raii_thread over std::thread unless you plan to detach()
• If two or more mutexes must be acquired at the same time, use std::lock
  addressed by CP.21: Use std::lock() to acquire multiple mutexes
• "When using a condition_variable, always protect the condition by a mutex"
  is one of the items already in issue #554
• "should non-virtual interface be promoted"
  is the subject of issue #768 with pr #777

I believe all these should be dropped and the rest converted to open github issues (if it's unclear whether a rule should exist) or stub rules (if it's clear the rule should exist, but the details are not ready).