This is the first part of allowing engines to be added dynamically.
They are placed into a folder in engines/ which must contain a file
named "configure.engine" to add the engine, which is pulled into the
top level configure script automatically.

This is the second part of allowing engines to be added dynamically.
Each folder in engines/ which must contain a file named "engine.mk"
containing the make definitions for that engine.

This is the third and final commit enabling fully pluggable engines.

Now providing an engine folder contains a configure.engine, engine.mk
and engine-plugin.h file, it will be picked up automatically by the
configure script.

This is now generated automatically by the configure script from the
engine directory names.

Each engine now only has to provide a single configure.engine file
adding the engine into the configure script, which then produces the
required other files automatically.

I could not try any generated project files since I do not have access to
the IDEs.

This is due to the multiple outputs produced by the configure rule,
which cause multiple invocations of configure when make is run in
parallel. Various solutions are detailed in the Multiple-Outputs
section of the GNU automake manual which apply generally to makefiles.

This solution is a simpler one, but should solve the problem, though it
can fail on "mutilated" trees ie. where some of the configure outputs
are present, but not all... but this situation is not common, tends to
be due to an error in configure and should be recoverable by a
"make clean && ./configure" call.

This is mainly "cosmetic" to keep the SCUMM engine and subengines at
the top of the various files, but probably a good idea to prevent any
subtle regressions associated with changing the order.

This makes create_project output consistent with configure output again.

…ject files.