Add stop_at_first_char option to the move/select/delete to beginning of line actions

[felixpackard]

Closes #7863

In order to make the behaviour of similarly named "[x] to beginning of line" actions consistent, I've added the stop_at_first_char option which, if enabled, will treat the first non-whitespace character as the start of the line, and otherwise will treat the first character (whitespace or otherwise) as the start. This option defaults to false, as based on my testing the default behaviour in VS Code, Vim, and Emacs is to use the "true" start of the line as opposed to the first non-whitespace character.

This option essentially overrides the stop_at_soft_wraps option if enabled, as if the movement::indented_line_beginning method is called with a stop_at_soft_wraps value of false, the actual line start will always be returned, rather than the indented line start. This feels somewhat counterintuitive, so if there's a better way I should be handling the case where stop_at_soft_wraps is false and stop_at_first_char is true, I'd be happy to implement it.

I've tried to be thorough with test cases, and I've included the new option in the default keymaps everywhere that the stop_at_soft_wraps option is specified, but it's entirely possible I've missed something, with this being my first contribution to the project. I'm always open to feedback and happy to pair.

Release Notes:

• Added stop_at_first_char option to the move/select/delete to beginning of line actions

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @felixpackard on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[felixpackard]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!