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

E.30: Remove suggestion to use `throw()`

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

Add clarifying example to SF.12

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.

Based on :
https://www.modernescpp.com/index.php/c-core-guidelines-type-erasure-with-templatesCo-authored-by: NVincent Legarrec <vincent.legarrec@csdental.com>

SF.12: Prefer the quoted form of `#include` for files relative to the…

... files that exist at a relative path to the file containing the `#include` statement (from within the same component or project)

explicitly note that "file" refers to as it exists in the location of it being authored/modified.
this is to address any confusion about #including "bar.h" from foo.h based on whether bar.h is relative to foo.h at the time and location foo.h is being modified (e.g. under mylib/foo.h) versus at the time/location from which foo.h is installed to the system and included by the user (e.g. from /usr/include).

Part of SL.str.1 references replacing “const string*” with “string_view”, but the example code above shows “const string&” instead.
This changes the comment to the reference rather than pointer.

It worth to mention the *structured bindings* right in the *Reason* section.

As a general rule, `operator()` should be const-qualified.
The exceptions are few and far between.

I was actually looking for a Guideline on that subject;
I grepped for `operator()` and found that not only is there
no such Guideline yet, the doc actually contained these
places that (needlessly) violated the general rule.

Using `this` in a free function makes the program ill-formed;
it doesn't magically give you a `std::thread*`.

The comments were:
// ???Must we suffer CaMelcAse???
and
// ugly CaMeLcAsEvArIaBlE

* Use '<thing> template' i.s.o. 'template <thing>'

The word 'template' is often wrongly used as an adjective to the 'thing'
it becomes when instantiated.

* Expand succinct formulation for readability
Co-authored-by: NKristoffel Pirard <kristoffel.pirard@vanhool.com>