Remove deprecated UNSAFE_componentWillUpdate in SLDSDataTable

[DNiederweis]

Fixes # Deprecation Warning in console about UNSAFE_componentWillUpdate which "promotes unsafe coding practices" - React Blog

Additional description

While UNSAFE_componentWillUpdate is called right before render, getSnapshotBeforeUpdate is called right before mutating the DOM. According to the React Documentation, the combination of getSnapshotBeforeUpdate and componentDidUpdate should cover all use cases for the legacy componentWillUpdate.

In this case since the purpose of using UNSAFE_componentWillUpdate appeared to be resetting the interactive elements for the datatable if the props differed, I moved this logic into getSnapshotBeforeUpdate. However, since getSnapshotBeforeUpdate gets the previous props rather than the next props, the if-statement had to be slightly adjusted. Additionally, because getSnapshotBeforeUpdate must contain a return statement(the return is passed as the third parameter to componentDidUpdate), it simply returns null. This change avoid the deprecation warning and enables the same behavior as with UNSAFE_componentWillUpdate.

---

CONTRIBUTOR checklist (do not remove)

Please complete for every pull request

• First-time contributors should sign the Contributor License Agreement. It's a fancy way of saying that you are giving away your contribution to this project. If you haven't before, wait a few minutes and a bot will comment on this pull request with instructions.
• npm run lint:fix has been run and linting passes.
• Mocha, Jest (Storyshots), and components/component-docs.json CI tests pass (npm test).
• Tests have been added for new props to prevent regressions in the future. See readme. - Not Applicable
• Review the appropriate Storybook stories. Open http://localhost:9001/.
• Review tests are passing in the browser. Open http://localhost:8001/. - 2 tests for SLDSCombobox fail("selects a menu item and scrolls when a letter key is pressed in read-only mode" and "selects menu items and scrolls when the down/up keys are pressed"), but they also did not pass after a clean install.
• Review markup conforms to SLDS by looking at DOM snapshot strings. - Not Applicable

REVIEWER checklist (do not remove)

• CircleCI tests pass. This includes linting, Mocha, Jest, Storyshots, and components/component-docs.json tests.
• Tests have been added for new props to prevent regressions in the future. See readme.
• Review the appropriate Storybook stories. Open http://localhost:9001/.
• The Accessibility panel of each Storybook story has 0 violations (aXe). Open http://localhost:9001/.
• Review tests are passing in the browser. Open http://localhost:8001/.
• Review markup conforms to SLDS by looking at DOM snapshot strings.

Required only if there are markup / UX changes

• Add year-first date and commit SHA to last-slds-markup-review in package.json and push.
• Request a review of the deployed Heroku app by the Salesforce UX Accessibility Team.
• Add year-first review date, and commit SHA, last-accessibility-review, to package.json and push.
• While the contributor's branch is checked out, run npm run local-update within locally cloned site repo to confirm the site will function correctly at the next release.

[welcome]

Thanks for opening this pull request! 💯

This is a community-driven project, and we can't do it without your participation. Please check out our contributing guidelines and review the Contributor Checklist if you haven't already, to make sure everything is squared away. CircleCI will take about 10 minutes to run through the same items that are on the Contributor checklist with a pass/fail check below. Please fix any issues that cause CircleCI to fail or ask for clarification--we try, but sometimes the errors can be unclear.
A maintainer will try to respond within 7 days. If you haven’t heard anything by then, please bump this thread. To ensure codebase quality, large code line changes may take more than 2 weeks to review, but may take longer depending on the number of pull requests in the queue. Feel free to ask for a status update at any time--you won't be bothering anyone.
Once feedback has been given, please reply to the feedback giver once the feedback on been addressed, so that they can continue the review.
If you need a release while you are waiting for a code review, you can publish a built tag to your own fork. See directions in the release README.