refactor(padding): follow python string padding conventions

[gforsyth]

Description of changes

This PR updates all backends to perform string padding in the same way that Python does, instead of the way that SQL does.

Python:

>>> "1234".rjust(2, "-")
"1234"

SQL:

D select rpad('1234', 2, '-');
┌──────────────────────┐
│ rpad('1234', 2, '-') │
│       varchar        │
├──────────────────────┤
│ 12                   │
└──────────────────────┘

In short, if the padding candidate is longer than the padding length, just leave
it alone.

BREAKING CHANGE: String padding operations now follow Python semantics and leave strings greater than the padding length untouched.

[gforsyth]

Oh, and while our padding was all over the place across various backends, I suppose this is a breaking change? I can adjust the commit message.

[jcrist]

For trino and oracle (and other backends that implement the SQL lpad/rpad), what about something like lpad(string, greatest(length(string), padlen), padstring) (untested)?

Or IFF(length(string) >= padlen, string, lpad(string, padlen, padstring)) (also untested and considering I can't remember if it's IFF or IIF)?

[gforsyth]

lpad(string, greatest(length(string), padlen), padstring)

that's a good idea!

[gforsyth]

lpad(string, greatest(length(string), padlen), padstring)

that's a good idea!

I actually decided to use this as the base implementation since it's easier to read (both in sqlglot and in SQL)

[cpcloud]

Great work! Thank you!