Before calling "attach" a screen object is just a dummy container for
(row, col) values whose purpose is to be sent as part of the "attach"
function call anyway.

Just create the screen in an attached state directly. Keep the complete
(row, col, options) config together. It is still completely valid to
later detach and re-attach as needed, including to another session.

Problem:
crash when calling nvim_buf_get_text() with a large negative start_col:

    call nvim_buf_get_text(0, 0, -123456789, 0, 0, {})

Solution:
clamp start_col after subtracting it from the line length.

Specifically, functions that are run in the context of the test runner
are put in module `test/testutil.lua` while the functions that are run
in the context of the test session are put in
`test/functional/testnvim.lua`.

Closes https://github.com/neovim/neovim/issues/27004.

Problem:  Renaming non-current buffer changes working directory when
          'autochdir' is set.
Solution: Temporarily disable 'autochdir'.  Add more tests for the
          win_set_buf change.

Work on https://github.com/neovim/neovim/issues/27004.

`exec_lua` makes code slighly harder to read, so it's beneficial to
remove it in cases where it's possible or convenient.

Not all `exec_lua` calls should be removed even if the test passes as it
changes the semantics of the test even if it happens to pass.

From https://github.com/neovim/neovim/pull/28155#discussion_r1548185779:

"Note for tests like this, which fundamentally are about conversion, you
end up changing what conversion you are testing. Even if the result
happens to be same (as they often are, as we like the rules to be
consistent if possible), you are now testing the RPC conversion rules
instead of the vim script to in-process lua conversion rules."

From https://github.com/neovim/neovim/pull/28155#discussion_r1548190152:

"A test like this specifies that the cursor is valid immediately and not
after a separate cycle of normal (or an other input-processing) mode."

This is the first installment of a multi-PR series significantly
refactoring how highlights are being specified.

The end goal is to have a base set of 20 ish most common highlights,
and then specific files only need to add more groups to that as needed.

As a complicating factor, we also want to migrate to the new default
color scheme eventually. But by sharing a base set, that future PR
will hopefully be a lot smaller since a lot of tests will be migrated
just simply by updating the base set in place.

As a first step, fix the anti-pattern than Screen defaults to ignoring
highlights. Highlights are integral part of the screen state, not
something "extra" which we only test "sometimes". For now, we still
allow opt-out via the intentionally ugly

  screen._default_attr_ids = nil

The end goal is to get rid of all of these eventually (which will be
easier as part of the color scheme migration)

fixes #27720