Added graph->dot function

It just prints out a valid graphviz graph, by using both nodes->dot and
edges->dot I previously defined in the lasts iterations.
Add function dot->png, that generates a png.

The purpse of this function is to write a digraph spec (in dot format) into a
file, and then call dot to create a png.
The function is designed to be generic, so it expects that the caller provides
a thunk, where the action of generating the dot from something specific is
passed. The idea is to leave this function just to do the IO part, all the
other logic, is wrapped in the thunk.
Added graph->png function, this function is called with a filename, an alist with the nodes, and alist with the edges.

This function is rather simple, and is the one which implements the thunk in a
lamda function, which is simply calling to graph->dot with the provided alists
for nodes and edges.
It has a little problem though, and is about the filename, the filename we
request is the dot filename, from which it generates a png using the file name
plus the extension .png. Which represents a minor problem, for instance if the
user wants to creat "test.png", the function will create a "test.png" with the
dot graph (in text) and a file called "test.png.png" to contain the actual png.
Attempt to avoid the filenaming problem when using the graph->png function

graph->png used the "fname" parameter to pass it as it is to dot->png, which
used that file name to print a digraph, and use it to call "dot", which in turn
will add a postfix (.png) to the filename.
Thus when we called
   (graph->png "test.png" *nodes* *edges*)

After its execution, a file test.png and a file test.png.png will be generated.
The problem is, that the user could try to open test.png and find out that it
does not work (since it is not a png, is a text file with the dot
description!).

To avoid the problem, I have changed the name of the parameter from fname to
prefix-fname, and I have also made that in graph->dot adds a ".dot" extension
to the file.
New approach to the problem, this time if the file have a .png extension, I replace it with .dot when generating the .dot file

With this new approach, two files are generated a file with the extension .dot
and a file with the extension .png, but we will remove the possibility of
having .png.png and .png.dot.

This is a result of an execution.

[1]> (graph->png "prueba.png" *nodes* *edges* )
T
[2]> (quit)
Bye.
darkturo@neverland:~/Learning/the-land-of-lisp/drawing-graphs$ ls
digraphs.lisp  prueba.dot     prueba.dot.png

For any other name the user may use, a .dot extension will be added to the
provided name when genrating the graph. And the same will happen when
generating the png, a ".png" extension will be used, i.e.

> (graph->png "superdoc.doc" *nodes* edges*)
> (ext:shell "ls")
superdoc.doc.dot superdoc.doc.png
Fixed little issue when calling graph->png, it returned nil.

(ext:shell) returns the return status of the executed command. In unix, this
status is by convention 0 when the command was executed correcly, or a
different number when it had failed for some reason. This behavior has been
passed to ext:shell, so it returns nil when it was okay, or a number when not.
Since we are encapsulating what we're doing inside the func,, I preffered to
encapsulate this detail and instead of showing nil or numbers, show true when
the exec was ok, and false (nil) when it didnt.
Merge branch 'exec-return-issue'

Conflicts:
	drawing-graphs/digraphs.lisp