Fix associtation and UI

# 前回PRとの関係
前回PRまで`user has many orders`で作っていました。
しかし、`user has one order`のほうが良いとわかりました。

`user has many orders`ですと、`app/views/arriveds/show.html.erb`で不具合が出ます。
リソース設計としても、このアプリケーションは注文に期限を設けない限り、１ユーザーは１つの注文しかできないのが自然と教えて頂きました。
そのため、修正します。

また、それとは別に、より良いUIにするため注文作成時のビュー変更作業をします。

## １オーダーにする理由について

### `user has many orders`の場合
----------------------------------------------------
「紅茶１個、緑茶１個」を注文したとします。その後で「烏龍茶１個と、追加の緑茶１個」を注文したくなったとします。
これをシステムに反映するには、注文「烏龍茶１個と緑茶１個」を新規に作成することになります。

この場合

* `user`が１つあり、 `order`を２つ持っている。
  * １つめの`order`は、以下２つの`order_detail`を持つ
    * 紅茶１個を意味する`order_detail`
    * 緑茶１個を意味する`order_detail`
  * ２つめの`order`は以下２つの`order_detail`を持つ
    * 烏龍１個を意味する`order_detail`
    * 緑茶１個を意味する`order_detail`

ということになります。
注文する緑茶は２個なのに、それを別々の`order` でわけていることが特に不自然なのだと思います。
（また、前回注文を削除して新規注文を作成するという方法もとれますが、同様に不自然なのだと思います。）
     
### `user has one order`の場合
----------------------------------------------------
同じことをしたくなった場合、以下のように、より自然な形で反映が可能です。

* `user`が１つあり、 `order`を１つ持っている。
* `order`は、以下３つの`order_detail`を持つ
     * 紅茶１個を意味する`order_detail`
     * 緑茶２個を意味する`order_detail` 
     * 烏龍１個を意味する`order_detail`  

# このPRで何をするか
* [x] `user has one order`にして、現状の機能を壊さないように他の場所も修正を入れます。
* [x]  `orders#edit`のビュー（ユーザーインターフェース）を大幅に変更します。

# 終了条件（どうしたらWIPが取れるか）
1. [x] `user has one order`かつ、常に`user`は`order`を持つようにすること。
2. [x]  UIを変更すること。
 * [x] `select`要素を減らして見やすくする
 * [x] 合計注文金額を出す
 * [x] 空白の商品名、単価を選んだ時は空白でないものを選択するよう促すメッセージを出す
3. [x] 規約や慣習に沿った、読みやすいコードであること。
4. [x] 主要な機能のfeature specとmodelのうち不安な部分のspecを書いてgreenにすること。
> 「ぶつかる」について、もう少し詳しく教えて頂けますでしょうか …?

主問い合わせでも`order_details`テーブルを参照しているので、主問い合わせでのそのテーブルと、副問い合わせのテーブルとで名前が同じなのを懸念していたのでした。動かして大丈夫ならよいかな。
個人的には、このあたりのを聞くときはログに出るSQLも貼っておいていただけると、言及しやすくてありがたいです。

> 以下のようにINでも書けますが、INではなくてEXISTSなのは、今回は行を絞れる親問い合わせを、子より先に実行したほうがいいからですね。

すみません、好みですw ただ、DBMS