Add Cline events and roofactor subtasks slightly

[cte]

Context

• Make Cline an EventEmitter so we can disambiguate between parent and child messages in RooCodeAPI.
• Make parentTask and rooTask immutable and passed through the Cline constructor.
• Get rid of isSubTask (redundant with parentTask).
• Clean up e2e tests and add some utils.

Implementation

Screenshots

before	after

How to Test

Get in Touch

---

Important

Refactor Cline to be an EventEmitter, update task handling in API, and enhance webview components for improved task and message management.

• Behavior:
  • Cline is now an EventEmitter, emitting events for task lifecycle changes (taskStarted, taskPaused, taskUnpaused, taskAborted, taskSpawned).
  • parentTask and rooTask are immutable and passed through the Cline constructor.
  • Removed isSubTask in favor of parentTask.
• API:
  • New API class in api.ts implements RooCodeAPI, handling task and message events.
  • MessageHistory class in message-history.ts manages task messages.
• Webview:
  • ChatView and App components updated to handle new task and message events.
  • Added handleChatReset in ChatView to reset chat state.
• Testing:
  • Updated ClineProvider.test.ts to reflect changes in task handling and event emission.

^{This description was created by for 4b23644. It will automatically update as commits are pushed.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4b23644

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ellipsis-dev]

The pull request contains a significant number of changes across multiple files, including refactoring, feature additions, and test updates. It might be beneficial to split this pull request into smaller, more focused ones to facilitate easier review and testing.

Here are some suggestions on how the changes could be split:

1. Refactoring Changes: Group all refactoring changes together, such as those in e2e/src/suite/extension.test.ts, e2e/src/suite/index.ts, and src/core/Cline.ts. This will allow reviewers to focus on code improvements and simplifications.

2. Feature Additions: Separate the feature additions, like the new API class in src/exports/api.ts and the MessageHistory class in src/exports/message-history.ts, into their own pull request. This will help in isolating new functionalities for testing and review.

3. Test Updates: Consider creating a separate pull request for test updates, such as those in e2e/src/suite/modes.test.ts and e2e/src/suite/subtasks.test.ts. This will make it easier to verify that the tests are comprehensive and accurate.

By splitting the pull request, it will be easier for reviewers to focus on specific areas and ensure a thorough review process. Let me know if you have any questions or need further assistance!