adding trigger pane

Change-Id: Ib229756ffa22ed18cf17e23a560534c6236f8b10
Model for the Trigger rule data

Allow to build a data model for the trigger rule definition.

Change-Id: Id5e2194c98ed0b6be3b07f36f321190d0dfdf876
Build RulesBuilderData and send it in JSON

Change-Id: I98e7ef71a82486018dfcd3563ff744ecb1865ed4
Refactor ListValue json formatting

Previously JSon format for ListValues was used for 2 purposes:
- OpenList management
- Cardwall rendering & edition

OpenList came first and the JSon format was done to match the JS library
used for the rendering of the field (ProtoMultiSelect). Hence the format
included "value" and "caption".

Cardwall needed a JSon representation of ListValues too and tried to leverage
on JSon done for openlist, so "caption" started to percolate outside the
initial scope.

The purpose of this refactoring is to clearly separate concerns:
- One specific format for OpenList to match what is needed by ProtoMultiSelect
- One standard format used by Tuleap itself (Cardwall and TriggerRule builder)

The later is meant to be THE reference Json representation of a form element
and a list value.

Change-Id: Ia4076251661cf45adee483d1db0ebe231e90ee6e
creating interface for adding new triggers

Change-Id: I11daa47100c6c5f5592fd1f20aa454e61367b1fa
Adapt JSon to match what is expected by UI.

- Index fields and trackers to ease manipulation in JS
- Conditions embbed the corresponding operator

Change-Id: Ibcba774cadb9742f83eb59172cb3ccfa69c41557
saving a new trigger and using real data

Change-Id: I54fd498c3d4d4955391d7c20312c1b17f5778186
Build rule from request

Transform a new Json encoded trigger rule into a PHP object for later usage

Change-Id: Ib4cf99a146f8a8d74d6772c404f2a4649b6ec6a9
Backend trigger rule validation propagated to the UI

Change-Id: If6576db56ae0f105c2aad7e82cc680af43185635
displaying existing triggers

Change-Id: I2e01acce874d589c6be588892c01ec0a64adfad0
Allow DB errors to be converted to Exceptions

Previously, DB errors emited notices and it was up to the developer to
care if the query was successfull of not.
Basically, if a query lead to an error (data correctness, server issue,
etc), if developer did a bad job of not taking this into account, the
execution flow continued (potentially with inconsistent data).

With this modification, once enabled, as soon as an error occurs, an exception
is thrown and if the developer didn't care to catch it, it aborts the current
work.

Change-Id: If20f1f02e5e7fda2c357144cd9cefa9827ac9d06
Implement persistency layer for rules

Change-Id: I8732e89c1133c11cd6cdb810cb836bc8d1172fc8
Existing rules are included in page flow

Change-Id: I4d89c1a1d3f1ee64ab20fb4c5b11c383e2e02433
Define triggers only for static list fields

Change-Id: Idfa7399bee33e653552008a000e5f9cfbfc99643
Fix fatal error on local unit tests validation

We need to stub a class from AgileDashboard into tracker's test suite.
So, locally, we have a fatal error because bootstrap.php cannot load this class.
I require it manually in order to remove this fatal error.
I don't know why, but Jenkins does not rise this error.

Change-Id: Id9a553aee8eab52fadcf2b1d60742c71e49981d5
Delete a rule in DB

- Modification are persisted to the DB
- There is a new route for deletion in controller

Change-Id: I2af23c81d7a39e886513cd999e12e1e34e572db8
refactoring UI code to use correct (and non-confusing) terminology

Change-Id: I34bd627f26b095f5a166d66d0a8c7e3c54ce0982
Merge "displaying existing triggers" into 4534_create_cross_tracker_rules
Merge "refactoring UI code to use correct (and non-confusing) terminology" into 4534_create_cross_tracker_rules
fixing display for tracker with no childen

Change-Id: If7ae61540d2ac07dc1fc21e807aaa3fd4e1a0bdd