Add session data in server

## 対応内容

以下の内容に対応

* セッションデータ対応
* mapId をサーバ側で管理できるように変更

### セッションデータ対応

（たぶん）userStore に 下記メソッドを追加．

* setSessionData(sessionId, name, value) - 指定した名前でセッションデータを保存する
* getSessionData(sessionId, name, callback) - コールバックで取得したセッションデータを取得する

今のところ getSessionData() では name が一要素しか対応してないので同時に複数の値を取得したい場合は複数回コールバックを呼ぶ必要がある．理由はセッションIDに保存する方法を redis にハッシュ型で格納しているから．対応案としては以下のものがある．

* 保存時にハッシュ型ではなく文字列型で保存して json 形式で取得，保存する．
  * デメリット
    * 保存時にセッションデータを保存し直すために取得しなおさなければならないため setSessionData() の実装が複雑になる
    * 一回の通信量が必要なデータだけでなくセッションデータ全体になる
* ハッシュ型のままデータ構造を保ち， getSessionData() メソッド内で行う複数回コールバックを async を用いて対応して隠ぺいする．
  * デメリット
    * getSessionData() の実装が複雑になる
    * redis に対して取得したい値の回数分リクエストを発行する必要がある

### mapId をサーバ側で管理できるように変更

クライアントで mapId を管理せずにサーバ側で確定情報を保持するようにする．
今までではいろんなところに埋め込みされていたり，イベントのチェインによって引き回されていたりしていて（これが非常に厄介） map を変更することが非常に困難だったため，稼働時に一箇所データを変更するだけで map の切り替えが可能なようにセッションデータとして保存する．これでおそらくマップ移動の実装が楽になるんじゃないかと思う．


## TODO

TODO: userStore にセッションデータ管理のメソッドがあるのが違和感があるが userId と密接に関係がありそうなので下手に分離すると意味がわからなくなるのでストアの構成を変更する必要があるかもしれないので考える
TODO: セッションデータの setter/getter の実装をうまくする
TODO: mapId はマップ切り替え位置やマップ移動スキルなどのアクションが発生しない限りは変わらないためクライアント側でうまくキャッシュしておく機構があると無駄なリクエストが減りそう
TODO: なんか websocket 経由のデータのうまいデバッグ方法あれば
TODO: 実は socket.io の room でマップ切り替えればよくね？という可能性もある
TODO: ともあれクライアントからのマップ変更要求が行えるイベント作れるのでマップ移動とか
TODO: やっとパスファインディング実験用のマップを追加して動作確認できる
TODO: と思ったけどクライアント側で mapId と tmx の対応が取れてないんだったのでクライアント側も対応必要