add: リリースノートに機械可読な<table>を置く

[qryxip]

内容

VOICEVOX/voicevox_core#810 のための変更の一つです。
(VOICEVOX/voicevox_core#810 から依存されているのは、このPRそのものではなく #44 です)

リリースするONNX Runtimeについて機械可読な<table>を置き、CORE側のダウンローダーから認識できるようにします。

関連 Issue

ref VOICEVOX/voicevox_core#810

スクリーンショット・動画など

その他

[qryxip]

懸念: https://discord.com/channels/879570910208733277/893889888208977960/1267039799068590144

CORE側ではcomrakとscraperでCargo.lockが630行膨らむし、やってることの絵面もやはりよろしくはない。

別案の一つとしては手書きのJSONをリポジトリに置いて整合性はテストで担保するというのもあるが、ビルド時に情報を作るという流れにも利点はある。となるとリリースノート上の<table>でもよい...?

[Hiroshiba]

コアのダウンローダー側見てみたんですが、リリースノートをパースする形で全然いいんじゃないかなと思いました！
ってことでレビューします！！

[Hiroshiba]

ほぼLGTMです！！

[Hiroshiba]

実は分ける理由ないかも･･･？

･･･うーん、難しいですね。。。
まあ別に深く考えず、何でもいいかな･･･。

あ、コア側からダウンロードするつもりならxcframeworksだけ分ける形は後々大変になるかもです。
何かとxcframeworksをくっつける可能性もあると思うので。

コアからxcframeworksもダウンロードするならdylibsとxcframeworksはわけない方が良いか、あるいはdylibsとothersとかにしておくとまだ変更に強そう。
xcframeworksをコアのダウンローダーからダウンロードしないのであれば何でも良さそう。（idをつけない方が良さそう･･･？）

まあたぶんdylibsとxcframeworksは分けときたいってことだと思うので、将来的なこと考えるとこっちをothersにしとくのが丸い･･･かなぁ。
増えるとしたらmavenとかunitypackageとかnpmとかですかねぇ。

･･･npmは増えそう！！だけどOS項目いらなそう！！
うーーーーーん。dylibs/xcframeworksでも別に良い気もしてきました。
わからん！

[qryxip]

VOICEVOX/voicevox_core#810 (comment)に対応するものです。
0c25909 (#43)
0c31816 (#43)

[Hiroshiba]

LGTM！！