refactor all the things

ok this PR is quite huge and changes nearly everything...
look at this demo to get an idea: http://dashboard.digitalkaoz.net/


we use `digitalkaoz/issues` for search and fetching projects and issues from **different** issue trackers (currently implemented are github and jira, could be extended to for e.g. gitlab)

we use `digitalkaoz/issues-bundle` for the symfony layer and persisting data retrieved from the "issues" library in a storage agnostic way (currently only elasticsearch, but e.g. doctrine should be a nobrainer)
this bundle also contains the `sync` and `search` commands

all other bundles are obsolete...because the whole filtering and layouting is done by a `reactjs`  + `cortexjs` application. its quite cool, no reloading, live filtering issues...

the styling is completely refactored to a `sass` variant

the project configurations has changed to a more simpler approach: 

```yml
        github:
            - dbu/dashboard                             # explicit repo
            - phpcr/*                                   # all user/org repos
            - symfony/[Console|Debug]+$                 # only symfony/Console or symfony/Debug
            - doctrine/(?!common|lexer)([a-z0-9\.-]+)$  # all but doctrine/common or doctrine/lexer
        jira:
            # jira is a bit special, create this string with app/console issues:jira-crypt
            - ENCRYPTEDSTRING https://jira.domain.com PROJKEY
```

frontend deps are managed by `npm` and `bower` so for building the application you need this tools globally installed on your system.

everything is more decoupled and focused on one thing.

the mobile fixes could need some love.

i think the whole refactoring could be a good base for further feature additions
its up to everybody, but i would never ever do a deployment where
composer would have to resolve the dependencies anew on the server. i
would never trust myself or anybody else to not ship a change that
breaks something (might be i relied on an implementation detail, might
be they where a bit daring with BC).

if you have several severs, its additionally a lot faster than having
each of them resolve things.

i feel cowboy style enough for running composer and downloading code
from other peoples github accounts at all ;-)

anyway, lets stop the philosophical disucssion here. for this
repository, i don't want to ignore the .lock file as i would consider
that bad practice, but i agree with removing the .lock file from tracked
files. people using this dashboard for themselves can fork it to a
private space and add the lock file and their configuration.