Retain existing URL parameters across different view types

A new method ```update_url_parms``` has been added to retain existing URL parameters in the request query string. This method is currently being called while setting the urls for some of the UI components like toolbar buttons and paging controls.
The main function of this method is to update the URL parameters based on the UI control type while retaining the existing parameters (with the exception of a few) at the same time.
This should address some of the issues related to routing errors or code crashes due to the absence of certain URL parameters.

Other than this change, a missing route for 'download_data' was added as well.

https://bugzilla.redhat.com/show_bug.cgi?id=1130223
@martinpovolny I could use ```Rack::Utils.parse_query``` here and have simplified the code in this method.

In theory, updating url parameters should not be that complicated. 
All that needs to happen is we update a URL params hash value, and then simply convert the hash to a URL using ```.to_query``` or an equivalent method.

However, in practice there are a lot of things at play here that need consideration and which are possibly complicating a seemingly simple task. For e.g. 
a) Having to deal with a String input and then parsing it to create a Hash
b) All the strings come from a .yml and do not have a fixed format. A few examples of the input strings are -
“?type=list”
“&refresh=y”
“main_div”, which is not even a url parameter
c) One other thing that I have added in the code is to maintain the position of the first parameter in the url.
For e.g. in the url below -
```
/vm/show_list?type=list&bc=VMs+running+on+2014-08-25&menu_click=Display-VMs-on_2-6-5&page=2&sb_controller=host
```
```?type``` is the first parameter, and the new code maintains it as a first parameter across all views since traditionally it has been our first parameter in the list views.
```.to_query``` and other equivalent calls tend to rearrange the parameters alphabetically. So a few additional steps had to be added to ensure that a parameter's start position is maintained.