Reference, arguments and all that jazz.

[Vincent Bergbauer <vi...@yahoo.com>]

Not quite ready for prime time but you might get bored this weekend...

- I have put Argument out of Commandline.
- Both Path and Argument now derive from a new class NestedDataType (it's a data type
  for nested element!), which implements the interface CompositeType.
- I have eliminated PathElement since Path can already contain Path and Strings (through append).
- FileSet implements CompositeType.
- Property has a new attribute: separator. When a property has a reference to a CompositeType,
  it can change its separator.

You can do all sorts of fun things with references as the build file test1.xml and its output on my
machine attest.

All this brings about some interesting issues:
- What should be allowed to be referenced? for example, you could reference a Property, but it
currently does not
   follow references (its toString() simply returns a value). If it followed references, it would
have to check for
  circular references. Same with any other task. Should we restrict references to DataTypes at this
time?
  Note that a Property is already a reference of sorts when you instanciate with ${myproperty}.
- To resolve circular references and, often to display data, a DataType needs to know what project
it is in.
  I have added constructors that take a Project argument. Maybe there should be a static method to
give you the
  current project (the top of the project stack) to avoid passing projects around.
- Since references essentially bypass the type system, you can get some interesting results. In this
implementation,
  Path and Argument try to do something reasonable. However, add more types, and their behaviors
could become
  quite obscure.

P.S.: On my machine (W2K, cygwin) patch seems to crash when given a multi-part patch file. For that
reason,
        I have made multiple patch files.

Cheers.
Vincent.