This section details on the original issue you should resolve

<issue_title>Bold (and possibly color) escape codes are not honored under FreeBSD.</issue_title>
<issue_description>## Bug Report

• [ ✅] Yes, I reviewed the contribution guidelines.
• [ ✅] Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

When running php wp-cli.phar from the command line (I haven't copied it to /usr/local/bin yet) the bold color sequences seem to not be displaying correctly. I see something like:

ESC[1mNAMEESC[0m

  wp

ESC[1mDESCRIPTIONESC[0m

  Manage WordPress through the command-line.

ESC[1mSYNOPSISESC[0m

  wp <command>

ESC[1mSUBCOMMANDSESC[0m

Which I think are the ANSI codes for "bold" and "reset".

I am on FreeBSD, which I know is not the most commonly tested platform, but all my other things that use ANSI seem to work okay. For examples: man ls, alpine, ls itself, and the like.

This is fixed if I set --no-color, however, my problem is that I think the embedded escape sequences aren't being honored on my system somehow. OR they didn't survive being stuffed into the .phar file somehow. (Usually, when I copy paste onscreen escape sequences, it doesn't work, here it does).

Describe how other contributors can replicate this bug

• follow the base install instructions to download the .phar file onto a FreeBSD machine: curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
• run it from the command line, ala php wp-cli.phar.

Describe what you expect as the correct outcome

Either plaintext output, or bold output.

Let us know what environment you are running this on

php wp-cli.phar cli info
OS:     FreeBSD 13.2-RELEASE-p2 FreeBSD 13.2-RELEASE-p2 GENERIC amd64
Shell:  /bin/csh
PHP binary:     /usr/local/bin/php
PHP version:    8.1.20
php.ini used:   /usr/local/etc/php.ini
MySQL binary:   /usr/local/bin/mysql
MySQL version:  mysql  Ver 8.0.32 for FreeBSD13.2 on amd64 (Source distribution)
SQL modes:
WP-CLI root dir:        phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:      phar://wp-cli.phar/vendor
WP_CLI phar path:       /data2/home/danm
WP-CLI packages dir:
WP-CLI cache dir:       /home/danm/.wp-cli/cache
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.8.1
%php -m | grep -i suhosin
%php wp-cli.phar package list
+------+---------+---------+--------+----------------+
| name | authors | version | update | update_version |
+------+---------+---------+--------+----------------+
+------+---------+---------+--------+----------------+

Provide a possible solution

Provide additional context/screenshots

• I have tried this with my terminal set to both xterm and xterm-256color.
• I have tried it both inside and outside of gnu screen (I've been using screen for decades now).
• I have tried it on the system console (via vmware fusion).
• I have tried it via both mosh and SSH.
• I have tried it as users who have /bin/sh set as their shell, as well as under bash.
• I have tried this under both the MacOS default terminal app (Ventura 13.5.1), as well as iTerm2 (Build 3.4.20)

...as well as various transmogrifications of the above.

In no case do I get bold text.

One possible hint is that FreeBSD still uses termcap, and not terminfo, as most of the linuxes do, so if the code is doing something using terminfo to tell if color is supported, this may be an issue. (I don't see anything about TERM, termcap, or terminfo in the code).

Add any other context about the problem here.

If applicable, add screenshots to help explain (you can just drag&drop images into the Github issue).
</issue_description>

Comments on the Issue (you are @copilot in this section)

I trust you in that something must be buggy here, but I haven't the faintest idea what it is.

Here's where the sections are made bold:

WP_CLI::colorize() calls Colors::colorize() under the hood:

Here's how that class is implemented:

https://github.com/wp-cli/php-cli-tools/blob/d788a2c79e02f2f735fbb2b9a53db94d0e1b...