因WebRtcPlayer中使用RtspMediaSource的共享指针，特定情况下引起媒体注销无法触发的问题。

- 重现步骤
    在ZL的webrtc demo页面推流
    浏览器打开如下html
    webrtc.html
    关闭推流器页面,推流器停止推流
    webrtc.htm浏览器console->network将观察到：即使推流停止，但webrtc sdp请求一直能成功获取sdp，且流媒体一直不注销

- 原因
        因为每个WebRtc 播放 SDP请求都会产生 WebRtcPlayer，产生RtspMediaSource的共享指针，产生强引用。
        而DTLS超时释放需要一定的时间，WebRtcPlayer销毁需要超时。如果请求sdp的时间足够短，强引用会一直存在。将永远无法触发媒体注销

- 场景
        webrtc播放存在重试，但是udp不通。DTLS无法创建
        有人对ZLM执行恶意攻击，短时间内不断请求SDP但是不建立WebRTC通信

getMediaList/getMediaInfo接口、on_media_changed hook新增支持字段如下:
{
    "codec_id" : 0,
    "codec_id_name" : "H264",
    "codec_type" : 0,
    "fps" : 0.0,
    "frames" : 1119, #累计接收帧数，不包含sei/aud/sps/pps等不能解码的帧
    "gop_interval_ms" : 1993, #gop间隔时间，单位毫秒
    "gop_size" : 60, #gop大小，单位帧数
    "height" : 556,
    "key_frames" : 21, #累计接收关键帧数
    "ready" : true,
    "width" : 990
}

* 部分hls中会出现类似[../]或者[./]的相对地址, 因此写了一个解析的方法

* 有时候上游http协议不规范会导致直接输出eof, 特别是在自动重试机制开启下, 容易造成定时器没办法初始化从而拉不到流但是session一直存在,所以需要做一个判断,如果没数据直接报错

修改 macos 最后一步运行目录release/linux/Debug/ 改为release/darwin/Debug/ 
参看build log  
https://github.com/ZLMediaKit/ZLMediaKit/actions/runs/4150150582/jobs/7179611556

mpegts/g711 payload改成固定模式

* fix typo in RtspSession.cpp

* Trying to send mjpeg via MultiMediaSourceMuxer

* Improved JPEGRtpEncoder::inputFrame code but still not working

* 优化代码

* 完善jpeg相关逻辑

* Micro fix

* FrameJPEG renamed to JPEGFrame according to ZLM style

* Modified  JPEGRtpEncoder::inputFrame and JPEGRtpEncoder::rtp_send_jpeg

* getVideoHeight(), getVideoWidth() and getVideoFps() in JPEGTrack

* mjpeg rtp打包避免内存拷贝/修复mjpeg rtp解包huffman_table size字段错误的bug

* 支持mjpeg pix type

* 优化性能

* add bom header