interfaces / implementations separation (was Let's discuss KDevelop4 interfaces and shell)

[Alexander Dymo]

Ok, Matt is right I indeed need to provide the reasoning for 
interfaces/implementations separation.

What do I mean when I talk about interfaces:
- interfaces should be abstract classes (whenever possible)
  which will expose only essential parts of KDevelop core functionality

What would be the purpose of such interfaces:
1) to explicitly expose the API to our plugins
	Our plugins do not need to have access to the whole
	functionality of core components. They should just
	listen to some signals, get some events and call
	some controller methods and the job of interfaces is just
	to declare what's available.

2) abstract, minimal, clean and independent interfaces would:
- make it easier for new developers to approach KDevelop4 development
  and understand the architecture
- make it easier to implement new plugins because plugin implementers
  would just have to look at interfaces to see what's possible in KDevelop

3) abstract, minimal, clean and independent interfaces would:
- allow us to not care about BC in the shell
	Our "shell" (read implementation of a plugin loader, project loader,
	main window stuff) should not be kept BC. Shell is evolving target
	and keeping BC there would make it harder to improve KDevelop.
- allow us to keep BC only for small interfaces
	This way shell and plugins can evolve in various ways but still the
	shell would load plugins and plugins would still be able to access
	core functionality

What I don't want our interfaces to do:
1) I don't want our interfaces to allow to implement another version of
  a platform. Nobody will do that and nobody needs that.
  From our experience with KDevelop3 and Kuanta, I'd conclude that 
  alternative platform implementation is a myth.

What I want our interfaces to be:
1) The entry point to understanding KDevelop architecture
2) The clear set of things all platform plugins can use/call/access/whatever.