The basic implementation of the incident management feature (issue #194)

## Implemented features

* Send an issue to an issue trcking system (only Redmine is currently
  supported) when an event happen.
* Extend hatohol-config-db-creator to configure connection settings for issue
  tracking system and event conditions to send.
* Show links of posted issues on the events page.

## Basic concept of the implementation

This modification extends the action mechanism. A new action type "IssueSender"
is added. It aims to reduce duplicated codes since the trigger mechanism of
sending issues is very similar with action mechanism. On the other hand it has
some different points compared with other action types:

* Only one IssueSender action is performed against one event because this
  feature aims to tie one issue to one event. When two or more IssueSender
  acitons are matched against one event, only the first of them is performed
  (the priority mechanism will be added later).
* It doesn't have ownership concept. The reason is same with above.
  The owner of all IssueSender actions is Hatohol system. The access control
  feature will be realized only by privilege.
* It's a built-in action, not a script or a loadable module:
  * It is executed in the Hatohol process (on dedicated threads).
  * End users can't customize its behaviour except necessary minimum settings.
* It stores not only action log but also issue information.

## TODO

### Short term (Until Hatohol 14.06)
  * Add unit tests of ActionManager for IssueSender type action.
  * Add more detailed ActionLogExecFailureCode for IssueSender.

### Middle term (Until Hatohol 14.09)
  * Synchronize various statuses of posted issues with issue tracking system.
  * Enable to change statuses of posted issues from Hatohol.
  * Show issue information on triggers page.
  * Enable to configure options from Hatohol client.
  * Add priority mechanism for IssueSender action.
  * Resolve obstructions against supporting redundant configuration.
    For example issue information is currently stored to the local cache DB, it shall be an
    obstruction for such usage.

This is a field for time, isn't it ?
If so, should we use more wide value for 2038y-problem?