php/embed (build system changes)

Hi Sascha, It may be helpful if I explained why I ended up implementing PHP/embed in the way I did. Several people expressed a wish for having phplib: embeddable PHP engine and library. They wanted to take advantage of the enormous function library that is available in PHP in their C programs. I thought the idea was good and that being able to execute snippets of your PHP code within a C application would be useful. The fist thing I tried was to modify the build manually to link all the files and produce the lib. This was not very useful, since many PHP functions require that the engine is initialized and I was unable to initialize the engine without a SAPI. So I decided, I'll create a dummy SAPI that will do nothing except initialize the engine to allow the C application to call PHP functions without segfaults all over the place. Since this was only a stub SAPI which needed no configure options I opted for putting the files in /main. The only thing that was remaining was to add a new class of files to be linked into the build system, so I created PHP_LIB_OBJS and a new target in the makefile called libs. I have looked into the alternative of making php/embed a proper SAPI but have decided against it because the modifications to the build system required for enabling the simultaneous build were too great. I appreciate your effort on making SAPI part of the build more flexible, but I really think that it is unlikely that such a level of flexibility is needed. I might be wrong, but I think that a typical user would very seldom require more than 1 SAPI + CLI + LIB to be built. Of course nobody at the moment needs phplib but hopefully some applications would start taking advantage of that. Yasuo was already mentioning the possibility of having tighter PHP<=>PostgreSQL integration, for example. I know that I should have brought this up before I made the commit, but hopefully it's not too late. Edin