- this probably should have been in commit c7c9a6e0 (2009-11-04)
  but got overseen in the HashTbl -> HashTable switch

- allow insert() and set() from a UList of Key
  This complements the existing erase(const UList<Key>&) method

- adjust code to more closely resemble sampledSets / sampledSurfaces

Conflicts:
	applications/utilities/postProcessing/dataConversion/foamToTecplot360/Allwmake

- adjust code to more closely resemble sampledSurfaces

- this allows something like this:
      fields( T U "Ua.*" );
  to select normal fields and all the adjoint velocity fields

Mark Olesen authored 15 years ago and Andrew Heather committed 15 years ago

- forgot to use readList in removeEntry, which caused the test failure.

- remaining problem:

it doesn't work as might be expected
This is the problem:

dict
{
   foo xxx;
   bar yyy;
}

dict
{
   baz zzz;
   #remove foo
}

This only removes 'foo' from the current scope (the second dict), since
it occurs before the dictionary merge does.

To remove from the final, merged dictionary, we'd need a new
deleteEntry type that would do the right thing on the merge before
self-destructing (ie, removing itself too).

- forgot to use readList in removeEntry, which caused the test failure.

- remaining problem:

it doesn't work as might be expected
This is the problem:

dict
{
   foo xxx;
   bar yyy;
}

dict
{
   baz zzz;
   #remove foo
}

This only removes 'foo' from the current scope (the second dict), since
it occurs before the dictionary merge does.

To remove from the final, merged dictionary, we'd need a new
deleteEntry type that would do the right thing on the merge before
self-destructing (ie, removing itself too).

- reduce duplicate code by using some HashTable methods directly

- could also be the default

- reduce duplicate code by using some HashTable methods directly

- useful when using alternative dictionary names/locations

- missing in 1.6.x as well

- make it easier for non-emacs users to generate some of the
  documentation

- space between keyword and bracket in 'for(..)', 'if(..)', 'while(..)'

- the blockMesh interface is splineEdge.H, selectable as "spline"

The first tests look fine - it works as expected for the case with
buggy polySpline reported on the forum. Should of course do some more
extensive testing.

The advantages compared to the current B-Spline implementation:

- Doesn't need a matrix solver.
- The coding resembles something that can be found in the literature.
- In contrast to the B-Spline implementation, it is fairly clear what
  is actually going on. I don't even know if the B-Spline are actually
  B-Spline, Beta-Splines or something else.
- Catmull-Rom splines seem to be what all the graphics people have as
  their stable workhorse.

We now have 3 different names for splines in blockMesh:
- "spline" - *new* Catmull-Rom for arbitrary segments.
- "simpleSpline" - B-Spline for a single segment
- "polySpline" - B-Spline for a multiple segments

Assuming the Catmull-Rom splines continue to behave nicely, there is
no reason to keep the other (broken) B-Splines. This would help clean
up the blockMesh interface too.

Placed the older ones under legacy/ for easier identification in the
future.

TODO:
- currently no handling of non-zero end tangents
- could be extended to handle closed loops, which might be useful
  for feature edges from CAD (eg, for the cvm mesher)