fixes #8794

Reported the underlying issue here:
https://github.com/rails/sass-rails/issues/406

Basically `@import` works like this:
* look for the file relative to the current file
* look for the file as an absolute path following the priorities in the
* asset load_paths

If the file can be imported as a relative path that will take
precedence.

So in order to pick up the head and tails inside customization rather
than in app/assets there are three possibilities:
1) use an absolute path. This is not as easy as it seems. There is no
way of indicating a path is meant to be absolute so we would have to
ensure it does not resolve to a relative path.
2) have a application.scss file inside the customization folder. Since
this is the main file it will be used instead of the app/assets one. In
there relative paths will now also default to the customization folder
rather than app/assets. Once we are in an app/assets file though it will
not go back to picking up customization with relative paths
3) use //= require instead of import. rails-sass advices against this as
each required file would be compiled on it's own and variables could not
be shared.

Going with option 1 here:
```scss
// application.scss:
@import "custom/head_import";
```

```scss
// custom/head_import.scss:
@import "head";
```

As long as there is no custom/head.scss in app/assets it will import
head as an absolute path and thus prefer config/custom over app/assets.

This seems like the best option for now as it does not require changes
to the deployments.

only use the <pre> tag if the response was a text message i.e. during dev errors.
Use the alert-danger class of bootstrap 3 rather than alert-error.

* reran the simple form initializer.
* wrapped submit buttons are now broken and need a fix.
* disabled confirmation validation in client side validations as the
  error message always is attached to the wrong field.

Sometimes the dev environment will send back a plain text response.
This causes the json parser to raise an exception and used to cause
the browser not to display any error message.

Now we dumpt the whole server response - which happes to also include the
backtrace. A lot more useful than doing nothing.

In production this should never happen as 500s get handled by the
ExceptionApplication / our ErrorsController there.

subrepo:
  subdir:   "app/assets/javascripts/srp"
  merged:   "9e1a417"
upstream:
  origin:   "https://leap.se/git/srp_js"
  branch:   "master"
  commit:   "9e1a417"
git-subrepo:
  version:  "0.3.1"
  origin:   "https://github.com/ingydotnet/git-subrepo"
  commit:   "a7ee886"

It was marked as submitted even when client side validations interfered.

fixes github issue #227