feat(storage-check): add storage check

[Nanboom233]

这项feature为baas添加了识别装备库存的功能，目前已经实现三服的导航适配及基本不失误的检测结果

主要的实现方法

主要使用cv2.matchTemplate方法来进行识别，先针对装备栏区域定位第一行所在位置（考虑到后续的滑动），并以此为基点划分块，再循环模板，取最高分的模板，并认为对于区域的装备即为模板对应的装备，随后进行OCR识别数量（若数量过大以K显示，则程序方面为保持数据的类型一致，转换为000（即舍弃后面的精度））
同时，这项PR将使用到的（常用的）matchTemplate的实现加入了core.image来方便后期调用
（注：后续装备模板识别使用的是matchTemplate 的SQDIFF模式，并添加手动取平均处理）

使用方法

1. 添加了imutils等库，因此可能需要重新安装依赖
2. 执行 bThread.solve("storage_check") ，结果将以json格式打印

目前存在的问题

1. （目前难以解决）国服因字体原因1和7 ocr 无法正确识别，包括换用其他模型仍无法解决
2. src中模板文件读取有些混乱，在观察后续如何修改，可能考虑在 [Proposal][Development] Integrate all navigator functions into one module and refactor the storage of rgb_feature and img_feature. #312 中执行
3. 目前输出是以模板名称作为keys的值，尚未就模板文件名与用户友善名称建立关系
4. 添加了新的主界面模板，但尚未适配到to_main_page中，因此to_main_page在遇到新模板时仅能通过recognition_failed_click来返回，该项也是关于 [Proposal][Development] Integrate all navigator functions into one module and refactor the storage of rgb_feature and img_feature. #312 考虑而暂时未做适配
5. 识别效率不高，据本人渣机dev环境下测试，识别25份装备图像大约使用了17秒。该份commit因此采用了多线程方案，在8线程环境下，可以将单页（25份装备图片）识别时间压缩至2~5秒，代价是在这段短暂的时间内用户电脑cpu占用率飙升

针对上述问题1，目前可能的解决方案

1. 通过旋转图片让1与7区分增大，或通过缩小截图区域等玄学方案
2. 手动为国服训练调优模型（尽管不太可能）
3. 针对国服暂时不启用数量检测（摆烂结局.jpg）

示例输出

{
    "empty.png": {
        "loc": [
            799,
            594
        ],
        "quantity": -1,
        "score": 29.694165737644
    },
    "equipment_icon_badge_tier1.png": {
        "loc": [
            1014,
            565
        ],
        "quantity": 308,
        "score": 356.52627986348125
    },
    "equipment_icon_badge_tier10_piece.png": {
        "loc": [
            905,
            413
        ],
        "quantity": 157,
        "score": 413.75485996705106
    }
}

示例说明

1. “empty.png”为空模板，即空位，程序在检测到空位或者翻页后未加入新装备（特殊情况：装备数量恰好为5倍数因而没有空位），认为已经识别完全并退出程序
2. loc,score仅为debug使用，在后续没有实际用途