freezing ORBit2's API

[Mark McLoughlin <mark skynet ie>]

Hi there,
	I logged a bug (#61584) a while ago that ORBit2 exposes way
too much internals in its headers. This concerns me because by freezing
these 'API's we'll be tying ORBit2 down to a commitment that would
make improvements of the codebase virtually impossible.

	The reason for this, it seems, is mainly to cater for language
bindings down the road. I'm not quite sure as yet how we can cater
for language bindings while at the same time not freezing major parts
of the ORB's internals.

	So, to make it clear what ORBit2 API is being frozen I've
wrapped ORB internals in #ifdef ORBIT2_INTERNAL_API and internals that
are used solely in stubs/skels in #ifdef ORBIT2_STUBS_API. The latter
will be frozen when binary compatibility is required.

	Any objections? If not, I'll release ORBit2-2.3.96 tommorrow.

Good Luck,
Mark.