fix(table): Mind borders when computing table width

[AdrienHorgnies]

closes #574

Please check the associated issue to understand what I'm fixing.

• I have read CONTRIBUTING.md.
• I have created a discussion that was approved by a maintainer (for new features).

[meowgorithm]

Hey! Thanks for the fix here. This is a duplicate of #567; let's consolidate our efforts there as it contains tests + I see a gotcha in this one where borders are hard-coded to a width of 1, which will not always be the case.

Dup of #567.

[AdrienHorgnies]

Hi @meowgorithm. Thanks for looking at my PR. I was waiting for some feedback before looking into tests.

I think you classified it as a duplicate too fast. Likewise, I ran my test script (the one from the issue) using the code from the PR#567, and I reproduced the issue; meaning the PR 567 doesn't fix this issue. I think both PRs fix separate issues, as my PR is about borders added by the table component and not by the cell's content.

[AdrienHorgnies]

I added a test.

Here's the test result without the fix:

--- FAIL: TestTableWidthEqualsContentLen (0.00s)
    table_test.go:168: output does not match, expected:
        
        ┌────────┐
        │0123456…│
        └────────┘
        
        got:
        
        ┌─────────
        │012345678
        └─────────
        
        diff:
        
        --- golden
        +++ run
        @@ -1,3 +1,3 @@
        -┌────────┐
        +┌─────────
        -│0123456…│
        +│012345678
        -└────────┘
        \ No newline at end of file
        +└─────────
        \ No newline at end of file
FAIL
FAIL	github.com/charmbracelet/lipgloss/table	0.024s
FAIL

And it passes with the fix.

[AdrienHorgnies]

• I see a gotcha in this one where borders are hard-coded to a width of 1, which will not always be the case.

How so? I didn't find the option.