Refactor the chat messages component

[jerray]

This pull request contains the following changes:

1. Move the logic responsible for sending prompts to bots and updating messages from the Vue components to the store.
2. Remove the reference to the ChatMessages component from the App component.
3. Rewrite the ChatMessages component using composition API.

I tried to make the behaviors not change. Please let me know if there's any issue with the changes.

[jerray]

关于这两个问题，我的想法是这样：

1. $matomo 作为参数是有问题的。一时没想到更好的方式临时这样实现了。看了下 vue-matomo 的代码，可以直接通过 window.Piwik.getAsyncTracker() 来获取。
2. 将 Vue 组件看作是函数，它的输入是 props，输出是一个 UI 片段。UI 如何展示是由输入的 props 和内部的 state 决定的。Store 是一个全局状态管理器，它的数据也可以看作是 props 来作为组件的输入。UI 组件应该尽量做到可重用和可替代，尽量少的参与数据处理逻辑。这样的话，就需要把数据处理的逻辑从 UI 组件中抽离出来，放到 Store 里应该是比较合适的。业务逻辑改变数据，由数据来驱动 UI 变化。

[sunner]

那如果用 MVC 来划分，组件肯定是 V，store 肯定是 M，就是 C 放在哪里的问题了。VUE 有没有单独搞 C 的结构啊？

坦率说，我一开始看 .vue 文件的三大块结构，是以为它的意思就是把这些都放在一起呢。script 主要管 C

[jerray]

Vue 本身还是 MVVM 中的 VM 角色，V 是 DOM，M 是数据，Vue 作为 VM 是数据和 DOM 之间的桥梁。往 MVC 上靠的话，确实没有单独搞 C 的结构，需要开发者自己处理。其实还是业务逻辑代码放在哪里的问题，常见的有3种方案。

1. 放在 component methods 里，简单直观。但是随着项目增长，组件可能会变得臃肿，扩展性很成问题，给重构也会带来很大难度。长期来看，不是一个很好的方案。
2. 放在 store 的 actions 里。如果用到了 store，那放 actions 里面是比较自然的做法。actions 本身还支持异步。随着项目增长，也可以把 store 按照逻辑分片。
3. 单独搞一套 service 层，业务逻辑都写到里面。项目足够庞大的时候倒是可以考虑。

[sunner]

学习了。按你的来~~~~