Prior to this commit, the `__swizzled_vec__` class was not precisely
specified.  We said that it had the same interface as `vec` except
for a small set of differences that we enumerated.  However, it became
clear after discussing with the original authors that this wasn't a
complete list of differences.

This commit adds a complete list of the members and friend functions
for the `__swizzled_vec__` type.  In many cases, the descriptions
simply defer to the `vec` specification, but there are also many cases
where the semantics are special for `__swizzled_vec__`.

The updated specification also describes `__swizzled_vec__` as a view
over the original `vec` object, which I think is what we originally
intended.  I intentionally removed wording like "may not be bound to a
l-value or escape the expression it was constructed in."  I think the
true restriction is that the lifetime of the `__swizzled_vec__` must
not outlive the lifetime of the underlying `vec`, which is the case
for any view.

I also intentionally removed the statement:

> Both kinds of swizzle member functions must not perform the swizzle
> operation themselves, instead the swizzle operation must be performed
> by the returned instance of `__swizzled_vec__` when used within an
> expression, meaning if the returned `__swizzled_vec__` is never used
> in an expression no swizzle operation is performed.

This wording made is sound like the point of `__swizzled_vec__` was to
delay the swizzle operation as a sort of optimization.  However, our
original intent was only to specify `__swizzled_vec__` as a view.

This commit also uses our updated style to specify the
`__swizzled_vec__` type, using a format that gives more horizontal
space for the synopses and descriptions.

Closes KhronosGroup#504

Improve the wording in the introduction of the section on
`__swizzled_vec__` based on review comment feedback.

Addresses a code review comment.  Some compiler implementations may not
allow the lhs of a swizzled vector assignment to have repeated
elements, so add a constraint to disallow this.  It should be easy to
implement this using normal SFINAE techniques.

Clarify the distinction between `__swizzled_vec__` and
`__swizzled_vec__</*unspecified*/>` when used in the synopses.

I got feedback that the convention of putting quotes around "this" to
indicate the C++ "this" object was confusing.  I did this in cases
where there was some ambiguity about which `__swizzled_vec__` we are
referring to.  Reword these sentences to find another way to clarify
the ambiguity.

We discovered after some implemenation experience that the definitions
proposed in the early commits of this PR don't support all of the
desired use cases.  A simple example is:

```
sycl::vec<int, 4> v;
v.swizzle<1>()++;
```

This won't compile because the declaration of `operator++` takes a
mutable reference to the swizzle object:

```
friend vec<DataT, NumElements> operator++(__swizzled_vec__& sv, int);
```

C++ language rules prohibit binding the temporary object returned by
`v.swizzle<>()` to the mutable l-value reference parameter to
`operator++`.

To fix this, we changed all the swizzle operators to take a `const`
reference to the swizzle object.  This makes sense because the swizzle
class is a view over the underlying `vec`, and member functions on a
view class are normally `const`, even for functions that mutate the
object that underlies the view.  The logic here is that the view itself
is not modified, only the object referenced by the view.

This raises a new problem, though, because we don't want to allow code
to change a `const vec` via a swizzle.  For example, code like this
should result in a diagnostic:

```
const sycl::vec<int, 4> v;
v.swizzle<1>()++;
```

To fix this, we replace `__swizzled_vec__` with two classes:
`__writeable_swizzle__` and `__const_swizzle__`.  We use
`__const_swizzle__` for swizzles of `const vec`, and this class
provides only the non-mutating operators.

Now that we have two swizzle types (`__writeable_swizzle__` and
`__const_swizzle__`), change the builtin functions to accept either
of them.

We used to enclose all the member function descriptions in a table, so
that the description and synopsis of each function was visually
enclosed in a single table cell.  This caused a problem with the PDF
render, though, because some table rows were too big to fit on a single
page, which causes an error when rendering the PDF.  Fix this by
eliminating the table.  Instead, put a horizontal line between the
descriptions of the functions to visually separate them.

Avoid line wrap in synopsis in PDF render.

Co-authored-by: Gordon Brown <gordon@codeplay.com>

Co-authored-by: Gordon Brown <gordon@codeplay.com>

Add a section documenting the destructors for the
`__writeable_swizzle__` and `__const_swizzle__` classes.

I debated whether we should require them to be trivial.  I think they
probably will be trivial in a typical implementation, but I wasn't
certain enough to put this in the spec.  For now, I just said that they
have no visible effect.  This allows an implementation to contain some
internal state that is destroyed by the destructor, but I suspect most
implementations won't require this.