Respect NO_COLOR and always show the command as a header when paging uv help output

[EliteTK]

Summary

Fix #16015 and address an additional issue where the pager prompt would be bold
regardless of NO_COLOR.

Test Plan

Ran the test suite and manually verified against less 679 and busybox v1.34.1.
Checked with and without NO_COLOR on both less, busybox less, and more.

[zanieb]

I'm a little sad to lose -P which I think is a strictly better experience for the majority of users (assuming BusyBox is fairly uncommon) since the prompt stays with you as you scroll. I'm not sure I care that it differs from cargo and git, e.g., cargo using man by default and has pretty simple handling

https://github.com/rust-lang/cargo/blob/ebd20d2454fb299834f07b8f5f164783b4e24248/src/bin/cargo/commands/help.rs#L82-L100

[zanieb]

I'm not tied to keeping -P though. I do like the header.

[EliteTK]

@zanieb An option to keep -P (although I think it would be good to have both in that case) would be to put it in the LESS environment variable. busybox less silently ignores it then. But I haven't checked if it's possible to smuggle spaces into the prompt in that case. There's also the case of handling user provided LESS values. It's probably fine to just append a space and our -P in that case though.

[zanieb]

Huh, surprised to find out that echo "hello" | LESS="-P foo bar" less works. That's kind of fun.

I don't have strong feelings. I'm happy to go with whatever you think is reasonable.

[EliteTK]

Regarding -P in LESS. I'd be happy to re-introduce it in a separate PR. I'd just like to spend a little bit of time understanding how that variable works and how dependable that behaviour is, to make sure it doesn't break some other less implementation.

[zanieb]

It's not a high priority so you should probably just open an issue to track the idea and move on to something else that'll build context on uv instead.