* Implemented a plugin structure called Doku_Component in inc/component.php
  * Scripts defined in "inc/components" provide the base classes of various types of components, e.g., actions in the current implementation
  * Scripts defined in subdirs of "inc/components" provide implementations of each type of component, e.g., various actions.
  * The class name of each component does not need to follow a special pattern, as long as they will not conflict with other classes in Dokuwik
  * Auto lo`ading php scripts in "inc/components" directory, recursively
  * Only the components that are not inherited by other classes will be used to create an object of the component. This allows easy extension o
* Better seperation of action logics, a Doku_Action class that extends Doku_Component is defined in inc/components/action.php, and various acti
  * The actions now are components and thus have their own classes of handlers that provides all the information needed to handle the action.
    * Each handler provides the action name that it can perform, and the required permission level for the action, and a handle method.
  * If the handle method returns a different action name, a redirection to perform the new action is automatically conducted.
  * An action that inherits another action will automatically replace the parent action as the new action handler
    * This is the consequence of component inheritence design, but the bad news is that it creates a coveat:
      * that _you_ have to make sure that these actions handlers respond to the same action.
* As a result, the more convoluted inc/actions.php is gone
* inc/load.php is changed to stop loading the now nonexisting inc/actions.php
* inc/init.php is changed to make use of inc/component.php, which automatically loads components/action.php and components/actions/*.php
* doku.php is changed to make use to Doku_Action::act($action) method instead of the act_dispatch($act) function