initial demo of new runner-adapter logic with fs adapter

THIS IS NOT READY TO MERGE.

It is meant to showcase the proposal for new runner-adapter logic and acts as a place to discuss and make it better. The code is not tested at all, but should give a good idea of the execution path.

The idea with the new logic would be the following:

1. Runner's listenTask call provides adapter a callback( error, task, db_state ) -parameter.
2. Adapter fetches tasks, locks them for processing and calls callback(null, task_object, { lock_or_transaction }) for each task individually.
3. Runner guarantees that if it does not receive the first error parameter, it will always do it's best to end the callback execution to a call to one of the following adapter functions: **disableListenedTask**( task, db_state, callback ) OR **updateListenedTask**( task, db_state, callback ).
4. Each of these adapter functions use the callback to signal that "disable" or "update" has been processed, and passes an Error as the first parameter if it did not.
5. If runner receives a callback call without Error as the first parameter, it submits the task to the controller job.

A succesfull execution path could look like this:

    Runner.startPolling()
      Runner --> Adapter.listenTask( function task_callback( error, task, db_state ) {} )
        Adapter.start_poll_loop();
    
    Adapter poll loop found something:
      LOCK = Adapter.get_lock( { TASK } )
      Adapter --> Runner.task_callback( null, { TASK }, { lock : LOCK }
        Runner.add_retry_timeout_to_task( { TASK } )
        Runner --> Adapter.updateListenedTask( { TASK }, { lock : LOCK }, function submit_task_callback( error ) {} )
    
    Adapter database update succeeds:
      Adapter.release_lock( LOCK )
      Adapter --> Runner.submit_task_callback( null )
        Runner --> Worker.submitControllerJobBg( { TASK } )