Edit: display warning for large @-mentions

[abeatrix]

The changes in this pull request address an issue where the total size of selected context items could exceed the character budget for the active model when importing through @-mentions.

The Edit Command Menu has been updated to:

1. Track the total size of the selected context items and compare it against the maximum character limit for the active model.
2. Display a "Large File Warning" label in the quick pick items if the size of a selected context item would cause the total to exceed the character budget.
3. Automatically remove any selected context items that are no longer included in the current user input.

Additionally, the filterLargeFiles function in editor-context.ts has been updated to store the file size in the ContextItemFile object, which is used in the getInput function to determine if a file is too large.

These changes help ensure that the user is not presented with context items that would cause the input to exceed the character limit, providing a better user experience and preventing potential issues with the editor's functionality.

Test plan

Follow-up

• Support @-mentions with range for Edit

[dominiccooney]

I'm concerned about the scalability of this approach. Because stat is cheap but tokenization is not. Once we move to token counting this may need to be very different.

So let's stop investing more in synchronous size checks, until we work out how to scale to (more) accurate token counting. Some ideas:

• Have a fast path for files which are definitely small enough, or definitely too large (for example, work out the smallest/largest byte -> token count expansion ahead of time and do a quick file size check to exclude tokenizing the largest files)
• Cache the token counts
• Do the token counts lazily, prioritizing items the user has already selected (which means we need to show errors after the user has chosen something) or that are visible in the quickpick (can we get what's visible from the VSCode QuickPick?)
• Get a smarter tokenizer, for example if we can stream, we could stop tokenizing as soon as we know something is too large

[abeatrix]

I'm concerned about the scalability of this approach. Because stat is cheap but tokenization is not. Once we move to token counting this may need to be very different.

So let's stop investing more in synchronous size checks, until we work out how to scale to (more) accurate token counting. Some ideas:

• Have a fast path for files which are definitely small enough, or definitely too large (for example, work out the smallest/largest byte -> token count expansion ahead of time and do a quick file size check to exclude tokenizing the largest files)
• Cache the token counts
• Do the token counts lazily, prioritizing items the user has already selected (which means we need to show errors after the user has chosen something) or that are visible in the quickpick (can we get what's visible from the VSCode QuickPick?)
• Get a smarter tokenizer, for example if we can stream, we could stop tokenizing as soon as we know something is too large

This is a follow-up on #3619 (comment)
I wanted to update this here first, so that I can standardize it in my WIP PR for expanding the context window and using token as size.
But I just realized that was asking to add support for entering range and not displaying large file warning 🤣

[dominiccooney]

@abeatrix

This is a follow-up on #3619 (comment)

Makes sense. It threw me for a loop in the context of this token counting change.

[umpox]

Nice!