Add system column rw_timestamp for any tables

[fuyufjh]

Is your feature request related to a problem? Please describe.

Expose rw_timestamp on any tables.

Because our subscription already exposed a timestamp rw_timestamp based on epoch, I think there isn’t any concern about exposing the internal epoch using a hidden column.

Besides, I think vnode and epoch is also useful in some cases. How about do them together?

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

Slack discussion https://risingwave-labs.slack.com/archives/C048771BGKF/p1691737477347599?thread_ts=1691732764.258889&cid=C048771BGKF

[github-actions]

This issue has been open for 60 days with no activity.

If you think it is still relevant today, and needs to be done in the near future, you can comment to update the status, or just manually remove the no-issue-activity label.

You can also confidently close this issue as not planned to keep our backlog clean.
Don't worry if you think the issue is still valuable to continue in the future.
It's searchable and can be reopened when it's time. 😄

[st1page]

Some additions: they can only be referenced by a batch query and not by a streaming query.

[chenzl25]

_rw_epoch and _rw_vnode look reasonable. However, do we need _rw_raw_value and _rw_raw_key?

[fuyufjh]

_rw_epoch and _rw_vnode look reasonable. However, do we need _rw_raw_value and _rw_raw_key?

Sorry, please ignore them. Let's start from rw_timestamp now. Please check this Slack thread for context.

[st1page]

_rw_epoch and _rw_vnode look reasonable. However, do we need _rw_raw_value and _rw_raw_key?

The requirements come from the debugging and trouble shooting for the tricky bugs such as https://risingwave-labs.slack.com/archives/C048771BGKF/p1691736276987669?thread_ts=1691732764.258889&cid=C048771BGKF