docs: stop prettier table re-alignment churn in expressions.md

[andygrove]

Which issue does this PR close?

N/A. This is a documentation/tooling change to reduce contributor friction.

Rationale for this change

docs/source/user-guide/latest/expressions.md is hand-edited by nearly every PR that adds or updates a Spark expression. The tables are formatted by prettier, which aligns each column to its widest cell. Adding a single row whose Notes (or any) cell is wider than the current column re-pads every other row in that table. The result is large, noisy diffs and frequent merge conflicts between concurrent expression PRs that each touch the same table.

What changes are included in this PR?

• Add a .prettierignore that exempts docs/source/user-guide/latest/expressions.md. The file is almost entirely tables, and prettier's markdown prose handling is whitespace-only (proseWrap defaults to preserve), so exempting the whole file costs nothing for the surrounding prose while stopping the column re-padding.
• Collapse the existing table padding to single spaces. With prettier no longer aligning the tables, removing the alignment padding means adding a row never shifts the other rows. Combined with the prettier exemption, every future addition is a true one-line diff that cannot collide on re-alignment. This is a one-time reformat (470 rows) with no content changes.

How are these changes tested?

Verified locally that prettier --check "**/*.md" passes with the file ignored (including after appending a deliberately misaligned row), and that all 20 tables retain consistent column counts after the reformat, with the escaped-pipe cell (`\|` in bitwise_funcs) preserved.

[mbutrovich]

Thanks @andygrove. So what's the workflow going forward for this file? Run prettier on it at release or something just to get it back into conformity?

[andygrove]

Thanks @andygrove. So what's the workflow going forward for this file? Run prettier on it at release or something just to get it back into conformity?

The short term answer:

• Viewing this in GitHub renders just fine and viewing source is arguable more readable than having everything padded
• This markdown gets published as HTML here and the prettier formatting doesn't impact this
• Yes, as part of the release process we do generate docs (i.e. compat guide) and run prettier so this would be prettified in release branches but not in main
• I guess the question is, do we care that the version in main is not prettified?

The long term answer:

• I'd like to generate this from source similar to how we generate the compatibility guide, and this content would no longer exist in the markdown document, so we would no longer have conflicts. I am prototyping this now in feat: generate expression reference doc from code [WIP] #4585