Map Concert Description property.

The Description property on a Concert was not being mapped between the domain model and the view model.  Additionally, the value of the property was still hard-coded in the Concert model, so this class has been updated as well to provide a public setter.  This means that, for now at least, Concert domain models are no longer immutable.
Require authentication for Create action.

Reinstate the [Authorize] attribute for the Create action: we don't want randoms creating concerts on our site!
Publish Concert: return a Bad Request response when null.

When publishing a Concert, if the supplied Concert view model is null, return a 400 Bad Request response.
Return No Content on successful edit.

When editing a Concert, the REST service should return a 204 No Content response when the edit operation completes successfully.  The 2xx response indicates a success, and there's no content to return in this instance.
Return 404 Not Found for a non-existent ID.

When editing a Concert, it's possible the client will request a Concert that doesn't exist in the database.  In that case, we should inform the client that this is the case, by returning a 404 Not Found.
Persist changes to the edited Concert.

If the view model is all ok, then the Concert can be persisted to the database.  RavenDB tracks changes to the model retrieved via a call to Load() or Query(), so this object must have its state mutated.  As such, I have introduced methods onto the Concert domain model to enable mutation of its state.
Enable support for publishing concerts.

Up until now, the concept of publishing concerts had only been a view-level thing.  This change brings it into the domain model so it can be persisted.
Update Concerts List view.

Add an explanatory header to the column containing a bunch of icons to illustrate that they're actions that can be taken on the associated concert.

Only display the Publish action icon if the concert is not published.
Only display published Concerts.

On the index page, only published Concerts should be displayed.  This is the point of the IsPublished flag.
Use separate view models for the REST API.

Create a new separate Concert view model for the REST API to contain the appropriate Web API attributes, and to be better represent Concerts on the wire.  This should help pin down the problems with the quick actions on the Concerts' list page (no concert ID is being presented to the UI).

Bring in AutoMapper from NuGet to handle the object-object mappings.  The manual approach in the MapperExtensions class was clunky but worked ok for just one mapping; now there are two mappings, it makes sense to bring in a more robust framework for handling this work.
Set Href property on Concert API view model.

When mapping a Concert domain model to an API view model, set the Href property from a magic string and the Concert's ID.  TODO: this mapping code needs to be moved to a profile and the magic string dealt with appropriately.
Implement quick publishing of concerts.

This is a fairly big change.  The API view model has been restructured to better represent what is displayed on-screen (e.g., single DateTime field for the concert date and start time).  The Knockout ViewModels for the Concerts feature have also been restructured to reflect this.  I'm not happy with the way this is done at the moment, and it seems like I need to refresh (and improve) my Knockout knowledge: the UI items bound to the IsPublished flag are not updating when the flag's value changes.

This change also enables camel-casing in JSON.NET, so there's no need to do case transitions in the Knockout ViewModels anymore.
Fix up Concerts list page.

Another big check-in, but this completes the initial work on Concerts.  Refactor the Knockout Concert ViewModel to be fully observable, and the Concert list ViewModel to bind to the Quick Add form: this means the quick add action can pull the data out of the ViewModel rather than having to query the form fields directly.  Publishing a concert now auto-updates the page as expected too.

Move away from HTML Helpers for the Quick Add form: the code is clearer using plain HTML and there's no model binding going on here that might be assisted by their use.

Complete the implementation of the POST action on the Concerts API controller.  A successful POST request should, in addition to returning a 201 Created, return the URI of the new resource in the Location header.  I have also opted to return the created object over the wire, as appears to be the best practice.  This has two somewhat unfortunate side effects:

  - Duplication of the new resource's URI: this is returned in the content of the response as well as in the Location header, as I have an Href property on the wire representation of a Concert.  This should be revisited, as it may be possible to pull out the URI for the client from the response.
  - The received view model must first be converted to a model for persisting in Raven, and then the saved model must be converted back to a view model for returning to the client.  This is to ensure the new resource's ID is set correctly in the response content.

Additionally, there seems to be a lot of set-up required for correct operation of the Web API during unit testing a POST request.  The complex logic and context required to correctly instantiate an ApiController will probably need pulling out into an extension method or something when I get to writing another controller.
Merge branch 'feature/concerts' into develop