Provide a more obvious way to create assistant actions

When implementing a problem resolution assistant for kdev-python,
I noticed some very strange behaviour in the assistants API: actions
would only be executed if they were added to the assistant in the
actions() method (which is const, and should not create actions!),
while creating them in the constructor of the assistant made them
show up, but do nothing when triggered. The root of the problem turned
out to be that the assistants are instantiated in the parse job,
thus if you create the actions in the assistant's constructor, they
will live in the parse job thread, not in the application main thread;
the KAction's created from the assistant actions however would
live in the main thread, because the method to convert iAssistantAction
-> KAction is called from the main thread. Thus, connections wouldn't
work correctly, as the thread of the receiver is not running an event loop.

The existing code, as said, smartly works around this problem by adding
the actions to the assistant in the actions() method the first time
it is called, which happens from the main thread too. This sucks,
mainly because it cost me two hours to figure out why my actions wouldn't
be executed when I created them in the constructor, but also because
the API defines the function as const (which it should be), but the code
just ignores this (by using const_cast).

So, the new behaviour is this:
* If you want to create "static" actions (i.e. always the same for a given
assistant), implement createActions(). It will be called when the list of
actions is empty and actions are requested.
* If something goes wrong with where your actions live, you will hit
an assert instead of it just failing silently.

REVIEW:110211