- there were previously no hashing mechanisms for lists so they
  would fall back to the definition for primitives and hash the
  memory location of the allocated List object.

- provide a UList::Hash<> sub-class for inheritance, and also a global
  specialization for UList<T>, List<T> such that the hash value for
  List<List<T>> cascades properly.

- provide similar function in triFace to ensure that it remains
  similar in behaviour to face.

- added SymmHash to Pair, for use when order is unimportant.

STYLE: use string::hash() more consistently

- no particular reason to use Hash<word>() which forwards to
  string::hash() anyhow

- treat as a List constant without requiring inclusion of ListOps.H

- replace use of emptyList<label>() with emptyLabelList directly.
  The emptyList<T>() casting is disallowed with many modern compilers
  and now marked as deprecated (expect early removal).

- relocate labelList typedef to List.H for more general access.
  Similar reasoning to having labelUList defined in UList.H

- test(), get(), set(), unset() with behaviour as per bitSet,
  to allow easier swapping out of boolList <-> bitSet.

- make the purpose more explicit, and reduces some work for the
  compiler as well.

- can assist the compiler in producing tighter code.

- relocated ListAppendEqOp and ListUniqueEqOp to ListOps::appendEqOp
  and ListOps::UniqueEqOp, respectively for better code isolation and
  documentation of purpose.

- relocated setValues to ListOps::setValue() with many more
  alternative selectors possible

- relocated createWithValues to ListOps::createWithValue
  for better code isolation. The default initialization value is itself
  now a default parameter, which allow for less typing.

  Negative indices in the locations to set are now silently ignored,
  which makes it possible to use an oldToNew mapping that includes
  negative indices.

- additional ListOps::createWithValue taking a single position to set,
  available both in copy assign and move assign versions.
  Since a negative index is ignored, it is possible to combine with
  the output of List::find() etc.

STYLE: changes for PackedList

- code simplication in the PackedList iterators, including dropping
  the unused operator() on iterators, which is not available in plain
  list versions either.

- improved sizing for PackedBoolList creation from a labelUList.

ENH: additional List constructors, for handling single element list.

- can assist in reducing constructor ambiguity, but can also helps
  memory optimization when creating a single element list.
  For example,

    labelListList labels(one(), identity(mesh.nFaces()));

- now also handles negative indices without issue.
  This increases its robustness for predicate type of use.

- use std::reverse_iterator adaptors, avoid the array-bounds warning
- use pointer arithmetic instead of dereferencing the internal array

- adjust logic to use 'operator<' instead of 'operator>' in sorting.
  This creates less work when making other classes sortable.

- consistent with C++ STL conventions, the reverse iterators should
  use operator++ to transit the list from rbegin() to rend().

  The previous implementation used raw pointers, which meant that they
  had the opposite behaviour: operator-- to transit from rbegin() to
  rend().

  The updated version only has operator++ defined, thus the compiler
  should catch any possible instances where people were using the old
  (incorrect) versions.

- updated forAllReverseIters() and forAllConstReverseIters() macros to
  be consistent with new implementation and with C++ STL conventions.

- this increases the flexibility of the interface

- Add stringOps 'natural' string sorting comparison.
  Digits are sorted in their natural order, which means that
      (file10.txt file05.txt file2.txt)
  are sorted as
      (file2.txt file05.txt file10.txt)

STYLE: consistent naming of template parameters for comparators

  - Compare for normal binary predicates
  - ListComparePredicate for list compare binary predicates

- makes it accessible for containers that manage their own storage
  and derive directly from UList.

- DynamicList::min_size() method to access the corresponding
  SizeMin template parameter.

- ensure consistency in the reserve size for the constructor

      DynamicList<..> lst(N);

  now has identical sizing as

      DynamicList<..> lst();
      reserve(N);

- improve functional compatibility with DynList (remove methods)
  * eg, remove an element from any position in a DynamicList
  * reduce the number of template parameters
  * remove/subset regions of DynamicList

- propagate Swap template specializations for lists, hashtables

- move construct/assignment to various containers.

- add find/found methods for FixedList and UList for a more succinct
  (and clearer?) usage than the equivalent global findIndex() function.

- simplify List_FOR_ALL loops

- add increment/decrement, repositioning. Simplify const_iterator.

- this makes is much easier to use labelRange for constructing ranges of
  sub-lists. For symmetry with setSize() it has a setStart() instead of
  simply assigning to start() directly. This would also provide the
  future possibility to imbue the labelRange with a particular policy
  (eg, no negative starts, max size etc) and ensure that they are
  enforced.

  A simple use case:

    // initialize each to zero...
    List<labelRange> subListRanges = ...;

    // scan and categorize
    if (condition)
       subListRanges[categoryI]++;  // increment size for that category

    // finally, set the starting points
    start = 0;
    for (labelRange& range : subListRanges)
    {
        range.setStart(start);
        start += range.size();
    }

This uses a concept similar to what std::valarray and std::slice do.
A labelRange provides a convenient container for holding start/size
and lends itself to addressing 'sliced' views of lists.
For safety, the operations and constructors restricts the given input range
to a valid addressible region of the underlying list, while the labelRange
itself precludes negative sizes.

The SubList version is useful for patches or other things that have a
SubList as its parameter. Otherwise the UList [] operator will be the
more natural solution. The slices can be done with a labelRange, or
a {start,size} pair.

Examples,
     labelList list1 = identity(20);

     list1[labelRange(18,10)]  = -1;
     list1[{-20,25}] = -2;
     list1[{1000,5}] = -3;

     const labelList list2 = identity(20);
     list2[{5,10}] = -3;  // ERROR: cannot assign to const!

- some functionality similar to what the standary library <iterator>
  provides.

  * stdFoam::begin() and stdFoam::end() do type deduction,
    which means that many cases it is possible to manage these types
    of changes.

    For example, when managing a number of indices:
       Map<labelHashSet> lookup;

    1) Longhand:

        for
        (
            Map<labelHashSet>::const_iterator iter = lookup.begin();
            iter != lookup.end();
            ++iter
        )
        { .... }

    1b) The same, but wrapped via a macro:

        forAllConstIter(Map<labelHashSet>, lookup, iter)
        { .... }

    2) Using stdFoam begin/end templates directly

        for
        (
            auto iter = stdFoam::begin(lookup);
            iter != stdFoam::end(lookup);
            ++iter
        )
        { .... }

    2b) The same, but wrapped via a macro:

        forAllConstIters(lookup, iter)
        { .... }

Note that in many cases it is possible to simply use a range-based for.
Eg,
     labelList myList;

     for (auto val : myList)
     { ... }

     for (const auto& val : myList)
     { ... }

These however will not work with any of the OpenFOAM hash-tables,
since the standard C++ concept of an iterator would return a key,value
pair when deferencing the *iter.

The deduction methods also exhibits some slightly odd behaviour with
some PtrLists (needs some more investigation).

- Introduce writeList(Ostream&, label) method in various List classes to
  provide more flexibility and avoid hard-coded limits when deciding if a
  list is too long and should be broken up into multiple lines (ASCII only).

- The old hard-code limit (10) is retained in the operator<< versions

- This functionality is wrapped in the FlatOutput output adapter class
  and directly accessible via the 'flatOutput()' function.

Eg,
    #include "ListOps.H"
    Info<< "methods: " << flatOutput(myLongList) << endl;

    // OR

    Info<< "methods: ";
    myLongList.writeList(os) << endl;

- constness on local variables, pre-increment on loops, parameter names

- outputs compound tags etc.
  Should only be called by itself or by a derived class.

- no reason to use post-increment in forAll() macro.

- use C++11 cbegin()/cend() method names for forAll*Iter() macros.
  These method names have been in OpenFOAM since 2009 and are also
  used by C++11 containers.

STYLE: nullptr instead of 0 in UList

consistency with UList/List and so that functions which take a UPtrList
argument can also be called for PtrList.

    //- Disallow default shallow-copy assignment
    //
    //  Assignment of UList<T> may need to be either shallow (copy pointer)
    //  or deep (copy elements) depending on context or the particular type
    //  of list derived from UList and it is confusing and prone to error
    //  for the default assignment to be either.  The solution is to
    //  disallow default assignment and provide separate 'shallowCopy' and
    //  'deepCopy' member functions.
    void operator=(const UList<T>&) = delete;

    //- Copy the pointer held by the given UList.
    inline void shallowCopy(const UList<T>&);

    //- Copy elements of the given UList.
    void deepCopy(const UList<T>&);

reverseList
inplaceReverseList
rotateList
inplaceRotateList

Remove reverse function from UList and call the ListOps from the other
reverse function.