Refactor public include files

[asfernandes]

No description provided.

[AlexPeshkoff]

Is it good idea to mix our .h files with boost in same directory? May be better add separate dir for our headers.

[asfernandes]

Is it good idea to mix our .h files with boost in same directory? May be better add separate dir for our headers.

Boost is in subdir impl/boost, I don't consider impl files to be together with boost. I would have no problem in create a separate subdir, but note we are already on include/firebird. I would hate to have include/firebird/impl/firebird.

[AlexPeshkoff]

I've missed the fact that boost is already in separate directory. Forget it.

[AlexPeshkoff]

Almost OFFT - I suppose distribution packagers will stop forgetting about firebird/impl subdir after this PR ;)

[aafemt]

Do plain C include files for old API really belongs to impl dir which AFAIU is supposed to be for implementation of the new API...?

[asfernandes]

Do plain C include files for old API really belongs to impl dir which AFAIU is supposed to be for implementation of the new API...?

Public C include files were ibase.h, ib_util.h and iberror.h. Your supposition of impl being only for the new API is wrong. impl is used for files that should not be included directly by user applications.

[aafemt]

impl is used for files that should not be included directly by user applications.

Such headers as sqlda_pub.h and consts_pub.h are better to be included directly to user applications in the case it performs dynamic loading of client library and don't want to mess with function definitions for static linking. It is the same as with windows.h which includes everything else: mostly it is used but in some cases it is avoided and separate include files are used. Let application developers decide.

[asfernandes]

I'll have no problem to publish more files in include/firebird (of course with better names - no _pub suffix) if others agree. But I think that should be done after this PR, which is about restructure things without new features.