Added xref, massaged summary.

Changed the example so that objects are not passed by reference to other thread contexts (though threads are properly synchronized).

* Add new rule ES.3 Don't repeat yourself

* Replace function example with more inclusive/neutral language

Add a reference to topic on libraries.

Closes #1703

Closes #1705

* Update C.83 with swap for resource mgmt.

The swap is useful to implement assignments idiomatically (e.g. copy-swap idiom).

With the current enforcement, to non-virtual classes, very simple classes (e.g. `trivially_copyable`, a struct encapsulating an stl container) are suggested to have a swap. This suggestion can be argued wrong since for very simple classes copy-swap idiom is not efficient (the creation of a third object on assignment is not needed, which copy-swap does).

* Rework C.83 according to PR comments.

Also removes the only use of `decltype` in the Guidelines, FTW.

Remove string_span, recommend using `std::string_view`, `std:::span,<char>` or `gsl::span<char>` instead (#1680)

The various guidelines now have consistent Enforcements.
All C-style casts are now consistently banned, including to `(void)`.
Cast to `(void`)` should be `std::ignore =` instead.
All functional-style casts are now consistently banned,  instead of
`T(x)` use `T{x}`.

Revert "Revert "Revert "Removed gsl::string_span, recommend using std::string_view, std::span<char>, or gsl::span<char> instead"""

This reverts commit 82416094.

Revert "Revert "Removed gsl::string_span, recommend using std::string_view, std::span<char>, or gsl::span<char> instead""

This reverts commit f15ee43a.

Revert "Removed gsl::string_span, recommend using std::string_view, std::span<char>, or gsl::span<char> instead"

This reverts commit 5257915d.

Removed gsl::string_span, recommend using std::string_view, std::span<char>, or gsl::span<char> instead

Removed the suggestion to use `throw()` from E.30 ("Don't use exception specifications"), as it was deprecated by C++11, and is rejected by C++20.

Fixing previous commit where we ate the whitespace after "may" in four
places (yay regex search `might[^\s]`)

In English, the word "may" is overloaded and ambiguous. This commit
changes it to "might" wherever possible, otherwise more specific
meanings like "can," "could," or especially "must" ("may not" -> "must
not" when that is intended).

* ES.103 examples updated, addresses Issue #1656

* Fix cpplint report: Res-overflow0.cpp:18:  Missing spaces around <=  [whitespace/operators] [3]

* added minor clarification.

* Update CppCoreGuidelines.md

Updated comment.

* Update CppCoreGuidelines.md

The examples in SF.12 are likely to encourage readers to always use the `""` form of `'#include` when including headers from the same project ([discussion](https://github.com/isocpp/CppCoreGuidelines/pull/1596#issuecomment-673266275)). However, in larger projects this may not always be appropriate; `<>` should be used for includes located via a header search path.

This proposed solution adds an example of the later, i.e. where `<>` is used to include a header from the same project.

- Add a cross-reference to C.139 and note that it doesn't matter whether
a function is declared with override or final if the whole class is
already final.
- Fix C.139 to make it clearer that it's about `final` on classes.