[Experimental] Simulate post editing with diff in comments

[ailisp]

As a part of the first milestone of #137. We plan to experiment difficult technical problems in storing posts in SocialDB. This is the major technical challenge that may block the entire plan so we'd like to figure it out earlier.

Problem

We want to reuse Near Social posts, which is stored in SocialDB for DevHub posts. But Near Social posts are not editable. To get the behavior of editing, we simulate by have a special marker on a post that attempts to another post. The content of this "editing post" is in diff format. Then the DevHub widgets should identify the "editing post" posts and apply the diff to the original post. Note that we also need to take permission into consideration. For this task, permission can be read from DevHub contract. Only "editing post" from users with permission should be applied and rendered.

User Story

As a user, I'd like to edit posts and comments on DevHub. These posts should be the same posts of Near Social.

Acceptance Criteria

• Implement a prototype of Near Social posts editing system with diff in comments, for DevHub
• Original posts should be render on DevHub
• "editing post" type of post can be collected, parsed as diff and apply to the original post in DevHub post widget
• Only "editing post" by authorized user should be applied. User permissions are loaded from DevHub contract
• "editing post" posts should also be Near Social posts instead of Near Social comments. Because comments are flat but we need nested comments
• Edit and diff generation, storing as "editing post" posts implementation details should be hidden from user. From user's perspective, they still use current DevHub editor to edit post.

[frol]

Just throwing some ideas here:

1. It might be useful to approach the whole task from the perspective that SocialDB is permissionless, BUT the viewers can either respect or ignore the data, so DevHub will apply restrictions as it likes while let's say NearOverflow (non-existing StackOverflow on BOS) will apply different filters to the same posts.
2. Edits could be viewed as "pull requests" (suggestions for changes), and it is up to users, BOS Feed, and DevHub to either apply them or not. So it might be neither a post nor comment key used in SocialDB. Comments can also be viewed as "extension" to a post, so "pull requests" may potentially reuse a similar design to comments.

Hints:
a. Explore "resharing" mechanism on near.social (which does not seem to be implemented on near.org), maybe it could also be useful.