Fix wrapping of parser results

[Martchus]

See https://progress.opensuse.org/issues/37519

The problem is that the parser output contains too long, unbreakable lines.

Looks good when using min-width: fit-content which currently requires vendor prefixes for Firefox and WebKit-based browsers:

Not sure how to fix this otherwise without JavaScript or even some server-side adjustments. Note that this won't work with IE, but I don't think we care.

[codecov]

Codecov Report

Merging #1695 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1695      +/-   ##
==========================================
- Coverage   89.68%   89.66%   -0.03%     
==========================================
  Files         136      136              
  Lines        9443     9443              
==========================================
- Hits         8469     8467       -2     
- Misses        974      976       +2

Impacted Files	Coverage Δ
lib/OpenQA.pm	69.23% <0%> (-2.57%)	⬇️
lib/OpenQA/WebAPI/Controller/LiveViewHandler.pm	94.44% <0%> (-1.86%)	⬇️
lib/OpenQA/Worker/Engines/isotovideo.pm	95.73% <0%> (+0.6%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a70c6e8...f18e19f. Read the comment docs.

[coolo]

@hellcp do you know an alternative?

[hellcp]

The biggest issue here is using a table, which will stretch past the viewpoint (same issue as with leaking monitors and build result box in OBS), I would say it's the only option unless you go with:

1. .row's and .col's, which would help with containing that stuff
2. vertically scrollable table as opposed to vertically scrollable page (.table-responsive)
3. artificial limit on max-width of cells
4. js solution

[Martchus]

@hellcp

1. So you're saying that the Boostrap grid system should be used instead of the table? This is a huge rework (note that the table is manipulated in JavaScript). So this option is doable, but certainly nothing for a quick fix.
2. That doesn't solve the problem. Since the table is very long, it would be even worse to scroll than. Further, the box showing the screenshot (which is not part of the table) would likely require extra handling.
3. You mean hard coding a pixel value for max-width (maybe different hard-coded values using media-queries)? This is not very nice.
4. I wanted to avoid it but maybe it is worth looking into it.

A fifth option: Ensure no word is that long on the server-side.

---

Likely 1. is the best in the long term, but not for an immediate fix.

Note that the only disadvantage of the PR is that it doesn't work with IE: https://caniuse.com/#feat=intrinsic-width