Trace/Stream: add methods to switch byteorder

[megies]

What does this PR do?

Show up some ways how to work around exceptions getting raised when trying to merge traces with different byteorder but otherwise being mergable.
Still not sure if we want to automatically adjust byteorder when needed as this might have side effects we don't think of right now maybe.. so maybe a more conservative option would be to show a meaningful error message if a merge is failing solely due to a byteorder mismatch that points at the option to manually force byteorder to a common one.

Kinda would like to hear thoughts.

Why was it initiated? Any relevant Issues?

fixes #3417

PR Checklist

• Correct base branch selected? master for new features, maintenance_... for bug fixes
• This PR is not directly related to an existing issue (which has no PR yet).
• While the PR is still work-in-progress, the no_ci label can be added to skip CI builds
• If the PR is making changes to documentation, docs pages can be built automatically.
  Just add the build_docs tag to this PR.
  Docs will be served at docs.obspy.org/pr/{branch_name} (do not use master branch).
  Please post a link to the relevant piece of documentation.
• If all tests including network modules (e.g. clients.fdsn) should be tested for the PR,
  just add the test_network tag to this PR.
• All tests still pass.
• Any new features or fixed regressions are covered via new tests.
• Any new or changed features are fully documented.
• Significant changes have been added to CHANGELOG.txt .
• First time contributors have added your name to CONTRIBUTORS.txt .
• If the changes affect any plotting functions you have checked that the plots
  from all the CI builds look correct. Add the "upload_plots" tag so that plotting
  outputs are attached as artifacts.
• New modules, add the module to CODEOWNERS with your github handle
• Add the yellow ready for review label when you are ready for the PR to be reviewed.

[d-chambers]

This seems like a straight-forward solution and a simple implementation. The only thing I can think of that might go wrong could be in writing the stream/traces to some binary format that assumes a certain byte order. However, since this behavior is something the user has to opt in to use I don't see how it could affect any existing codes.

[megies]

I added some improved error messages on failed merges (e.g. due to dtype mismatch) and also added tests. Should be good to go now