Reorganized acceptance tests. Now tests related to folders are in their own file.
WIP: add a button that enables the user to associate a subscribed feed with a folder (already existing or created on the spot) or remove it from all folders.

Added callbacks to Feed and Folder methods to ensure that a given user can only associate a feed with a single folder. This means that if the user wants to associate a feed with a different folder, it will first have to be  removed from its current folder. This is a behavior that may change in the future depending on user feedback, but for the moment it seems the simplest behavior.

Implemented: The button is a dropdown that shows the list of folders that belong to the user, as well as "No folder" and "New folder" entries. A tick icon will be visible besides the folder to which the current feed belongs, or besides the "No folder" entry if the feed is not associated with any folders.

Not yet implemented: Associating a feed with an already existing folder, associating a feed with a new folder (created on the spot), removing a feed from all folders (by clicking on the No Folder link), deleting a folder which has no more feeds associated.

All user actions only affect the association of feeds subscribed by the current user to folders owned by the current user. A user cannot affect folders owned by other users at all.
Fixed broken acceptance test.

The CSS selector used to check the contents of the folders dropdown menu was wrong.
Added plus-icon to the "New folder" option in the folder dropdown menu.
Minor change in a i18n string.
Added a (still not fully implemented) acceptance test for adding a feed to an already existing folder.
Added routing and methods in Folder and FolderController that allow a user to associate a feed to a folder.

The user must be subscribed to the feed and the folder must be owned by the user. If the feed is already in another folder that belongs to the same user, it is removed from that folder before associating with the new folder. This means that from the point of view of a given user, a feed can only be associated with a single folder. This behaviour has been chosen for simplicity, but may change in the future depending on user feedback.
When a user adds a feed to an already existing folder, it is removed from the old folder (if any) and moved to the new folder in the view. The tick in the dropdown is also updated to show the current folder.

The "All subscriptions" folder is not affected, the feed remains there unchanged.

Not visible to the user, but also important: data-* attributes are updated to reflect that the feed is in a new folder.
Minor change in a coffeescript comment.
Fixed refreshing of folders and feeds.

Previously we were composing the refresh URL with javascript, simply appending "/refresh" to the feed path. This does not work very well if the current path has parameters, for instance the locale; a feed path like "/feeds/1?locale=en" would give a refresh path like "/feeds/1?locale=en/refresh" which does not work at all (the request is routed to FeedsController#show instead of #refresh, and params[:locale]="en/refresh" which is a weird locale indeed.

I've opted for including the feed (or folder) refresh path in a data-* attribute in the feed/folder links in the sidebar. When the user clicks on a feed (or the "read all subscriptions" link under a folder), the data-refresh-path attribute of the link is copied to the data-refresh-path of the refresh button; this means that the path accessed via AJAX to refresh feeds and folders is originally composed in the server (in the _sidebar_feed and _sidebar_folder partials, to be specific).

To make sure the refresh URLs are correctly composed, I've changed the feed and folder routes to named routes (feed_refresh and folder_refresh, respectively). This enables the use of feed_refresh_path and folder_refresh_path helpers in the views, which always compose the correct paths, parameters and all.
Added the data-sidebar-feed attribute to all the links in the sidebar to read feeds and to read whole folders. The javascript that detects clicks on feeds in the sidebar now works by detecting the presence of this attribute. The value of the attribute is inconsequential, its presence is what matters to indicate that a link is a sidebar link to a feed.

Before this change, the javascript events detected the presence of the data-feed-id attribute. However this attribute was also present in some other elements (e.g. the Folder button) and this caused strange behaviors. It's much better to have an attribute that unequivocally indicates that a link is a sidebar link.
Added regression test for bug #151, which was fixed by commit ab589552878da1ff534f061c4db44b503f201cff.

The bug was: when unsubscribing from a feed, the Folder button was deleted, and it never appeared again when clicking on a feed to read it.
Moved coffeescript file with code relative to feeds to its own folder under app/assets/javascript.
Break down the huge feeds.js.coffee file into several coffeescript files related to specific features: refreshing a feed, unsubscribing from a feed and so on.

This helps code management and makes future maintenance easier.
When there is a problem associating a folder with a feed, an alert is shown.
When a user tries to associate a feed with the folder it's already associated with, an alert is shown.
When successfully unsubscribing from a feed, the FeedsController returns an HTTP 204 code, instead of a 200. This is more in line with intended HTTP usage.

This will also be useful for the FoldersController: when removing a feed from a folder, a 204 will be returned if there are still feeds in the folder, and a 205 if there are no more feeds in the folder. This will tell the client whether to remove the folder from the view. This is not yet implemented.
Renamed the Folder.associate method to Folder.add_feed.

This is much more descriptive. Also this way it's more evident that the Folder.remove_feed I'm currently implementing is more-or-less the opposite to add_feed.
WIP: user can remove a feed from a folder.

The way it will be implemented, the user can:

- click on "no folder" in the dropdown, removing feed from all folders
- if the feed is in a folder, click on it in the dropdown to remove the feed from this folder

Currently both behaviors are exactly the same, because currently feeds can belong to a single folder for a single user. However, by implementing it this way, it would be easier to change the app to allow feeds to belong to several folders, if we so decide in the future.

Currently implemented: routing, FoldersController#destroy method, skeleton of the Folder#remove_feed method, FoldersController unit tests.

Not yet implemented: most of the Folder#remove_feed method, unit tests for this method, all javascript necessary for this to work client-side, acceptance tests.
Implemented the Folder#remove_feed method. This methods removes a feed from a folder and, if no more feeds are in the folder, deletes it from the database.

In the end I've decided to remove support for passing the value "all" instead of a folder_id to the method. This would have meant passing the user id as an argument, because we never want to remove a feed from ALL folders, at most we could want to remove it from all folders belonging to a single user.

As this is a option that was not going to be used at the moment and which adds some unnecessary complexity, it's been removed from the roadmap for now.