Fneves/autocomplete tags on deploy

## Description

This pull request adds the ability of having autocomplete with branches and tags on the autocomplete screen.
It also bumps up the version of typeahead javascript plugin supporting the new suggestion engine Bloodhound.

This works in two different ways:
1. If there is no locally cached repository, it gets the tags and branches remotely using git ls-remote command.
2. If a locally cached repository exists, it pulls the last changes and queries it for its branches and tags. 

All the changes are cached for so that multiple consecutive requests don't trigger multiple pulls or git ls-remotes in a short period of time. This cache uses a default TTL of 30 minutes and has an extra parameter (hit_count) that guarantees that if we hit the endpoint at least 6 times, it will refresh the cache even before the TTL.

The option of using git ls-remote when the repository is not locally cached is due to the fact that a big repository when cloned might take some time, and the repository would be locked for all that time.

This is an autocomplete feature meaning that the user does not really want to wait a long time to get the autocomplete suggestions and it would be strange that his deployment would then be waiting for a lock on the git repo. 
This way we use the git ls-remote to return the tags long way before the repository would be cloned.

## Screenshots: 

![versions](https://cloud.githubusercontent.com/assets/647255/5061127/39ff6a38-6d7b-11e4-9e7e-0ed8c682a359.png)

![autocomplete](https://cloud.githubusercontent.com/assets/647255/5061128/3e0236a6-6d7b-11e4-917f-06ad7fa2b65d.png)

/cc @zendesk/samson @pswadi-zendesk 

### References
 - Jira link: [SAMSON-109] (https://zendesk.atlassian.net/browse/SAMSON-109)

### Risks
 - There was some refactoring on the JobExecution so that the logic of repository setup could be shared between two controllers. Although all the tests should cover this refactoring we should keep an eye for possible problems that might show up from cloning repositories.
We should settle on one method for each, otherwise we're doubling the effort to support the feature