DOC: fix typos in the documentation files

This fixes several obvious typos in the documentation:

s/elvoved/evolved
s/performend/performed
s/importnat/important
s/sharedd/shared
s/eveyone/everyone

No backport needed.

doc/coding-style.txt

@@ -3,7 +3,7 @@
 
 A number of contributors are often embarrassed with coding style issues, they
 don't always know if they're doing it right, especially since the coding style
-has elvoved along the years. What is explained here is not necessarily what is
+has evolved along the years. What is explained here is not necessarily what is
 applied in the code, but new code should as much as possible conform to this
 style. Coding style fixes happen when code is replaced. It is useless to send
 patches to fix coding style only, they will be rejected, unless they belong to

doc/configuration.txt

@@ -5718,7 +5718,7 @@ It is possible to chain a TCP frontend to an HTTP backend. It is pointless if
 only HTTP traffic is handled. But it may be used to handle several protocols
 within the same frontend. In this case, the client's connection is first handled
 as a raw tcp connection before being upgraded to HTTP. Before the upgrade, the
-content processings are performend on raw data. Once upgraded, data is parsed
+content processings are performed on raw data. Once upgraded, data is parsed
 and stored using an internal representation called HTX and it is no longer
 possible to rely on raw representation. There is no way to go back.
 
@@ -5736,7 +5736,7 @@ HTTP/2 upgrade, applicative streams are distinct and all frontend rules are
 evaluated systematically on each one. And as said, the first stream, the TCP
 one, is destroyed, but only after the frontend rules were evaluated.
 
-There is another importnat point to understand when HTTP processings are
+There is another important point to understand when HTTP processings are
 performed from a TCP proxy. While HAProxy is able to parse HTTP/1 in-fly from
 tcp-request content rules, it is not possible for HTTP/2. Only the HTTP/2
 preface can be parsed. This is a huge limitation regarding the HTTP content

doc/internals/api/buffer-list-api.txt

@@ -5,7 +5,7 @@
 
 The buffer list API allows one to share a certain amount of buffers between
 multiple entities, which will each see their own as lists of buffers, while
-keeping a sharedd free list. The immediate use case is for muxes, which may
+keeping a shared free list. The immediate use case is for muxes, which may
 want to allocate up to a certain number of buffers per connection, shared
 among all streams. In this case, each stream will first request a new list
 for its own use, then may request extra entries from the free list. At any

doc/intro.txt

@@ -1693,7 +1693,7 @@ A small team of trusted developers will receive it and will be able to propose
 a fix. We usually don't use embargoes and once a fix is available it gets
 merged. In some rare circumstances it can happen that a release is coordinated
 with software vendors. Please note that this process usually messes up with
-eveyone's work, and that rushed up releases can sometimes introduce new bugs,
+everyone's work, and that rushed up releases can sometimes introduce new bugs,
 so it's best avoided unless strictly necessary; as such, there is often little
 consideration for reports that needlessly cause such extra burden, and the best
 way to see your work credited usually is to provide a working fix, which will