the native ProposeSync support

In both the node.Propose and the raft example, an unreliable way to submit requests is used. In etcd raft, Propose will return when msg append into msgsAfterAppend or msgs.(May be I'm wrong?)

And in raft example, v send to channel then return:

```go
func (h *httpKVAPI) ServeHTTP(w http.ResponseWriter, r *http.Request) {
key := r.RequestURI
defer r.Body.Close()
switch r.Method {
case http.MethodPut:
v, err := io.ReadAll(r.Body)
...
h.store.Propose(key, string(v))
w.WriteHeader(http.StatusNoContent)
return
...

func (s *kvstore) Propose(k string, v string) {
var buf strings.Builder
if err := gob.NewEncoder(&buf).Encode(kv{k, v}); err != nil {
log.Fatal(err)
}
s.proposeC <- buf.String()
}
```

I know that this is leaving Wait to the user to implement on their own, where they can choose their own timing to end Wait or even not Wait. But I guess most of the person that use raft want more reliability, so I have two proposals

1. put the wait interface and its default implementation from etcd into draft, and add new methods such as ProposeSyncApplied (wait for entry applied), ProposeSync (wait for entry commited, but not yet applied), and so on (or use option to distinguish between these behaviors). This requires adding a UUID to each Entry, and also allows the user to specify this UUID to be compatible with etcd's current RequestV2.ID.

2. Improve the raft example, the raft example should have a high reliability, after the user is familiar enough with the raft, adjust the behavior of the program to sacrifice reliability for performance. This can be done with https://github.com/etcd-io/raft/issues/2 (PS: I think the raft example can be simpler, there is no need to implement a persistent store and a real network layer, but there is a demonstration of the use of each method of the node)

I would like to know what you guys suggest and what is planned for etcd-raft in the future ~ I would also like to update some documentation and other contributions for etcd-raft, but I saw the milestone for etcd-raft 4.0 and I would like to know what is planned for 4.0 and when it will be available!

Start by reviewing node.Propose and the raft example's httpKVAPI.ServeHTTP and kvstore.Propose paths, then compare their request-submission behavior with etcd raft's Propose handling. Review the linked etcd-io/raft issue #2 and the existing discussion before defining whether synchronous commit or apply waiting belongs in the library or only in the example; completion requires an agreed API or example change and corresponding tests or documentation.

Written by the indexing model from the issue text.