Virtual scroller sizing behavior is not responsive

[PMabMI]

What kind of change does this PR introduce? (check one with "x")

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior? (You can also link to an open issue here)
Current the width of the virtual scroller is fixed at creation. This can result in strange behavior with the horizontal scroll when the window is resized for the "force" column mode. For example:

Minimum width of the columns is 600px. Table is initially rendered at 1000px width. The window is then resized so that the table has a width of 800px. If horizontal scrolling is enabled, the horizontal scroll bar will appear even though the columns have no hit their minimum width yet.

What is the new behavior?
I've updated the DataTableBodyComponent to handle the sizing of the datatable-scroller element in the same manner that the DataTableHeaderComponent handles the sizing of its inner html element.

Does this PR introduce a breaking change? (check one with "x")

• Yes
• No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...

Other information:

[PMabMI]

I ran into an issue that could happen with shrinking columns (and attempted to submit, but forgot to run the tests and it broke one) that is related to this pull request. The issue is found in the "forceFillColumnWidths" method in math.ts.

Sometimes when shrinking forced columns I noticed that sometimes it didn't fully shrink the columns to the new size (larger than the minimum total width and scrollbarH is false). I found that the resize will only loop if the remaining size is > 0, and will only execute the resize once if the remaining size is < 0 (i.e. shrinking). I attempted to fix this by changing the check to remainingSize !== 0, but when running the test this resulted in an infinite loop as the column was not actually resized when allowBleed was true.

I've updated the logic to behave in the manner that I personally would expect and updated the test spec with new cases. If these don't fall in line with your expected behavior please let me know and I'll work with you to get them updated