Remove ObjectMapper parameter from AssemblylineClient constructor

[cccs-mk]

Given the limited scope and constrained usage of the ObjectMapper in AssemblylineClient, it might make sense to just construct a brand new instance instead of accepting one as a parameter.

Coming from a different angle: What configuration changes by users are we trying to support by accepting a pre-configured ObjectMapper?

Originally posted by @cccs-mk in https://github.com/CybercentreCanada/assemblyline-java-client/issues/26#issuecomment-916327760

[cccs-mk]

The use cases I can think of for having an externally-configurable ObjectMapper feel fairly niche:

• A user wants mapping to be stricter (or less strict) about which fields are present in the AL JSON.
  • While this is possible, the Java objects will still only have the fields defined in the relevant class(es).
• AssemblyLine suddenly makes a minor change to their JSON format (e.g. snake_case to camelCase; new date/time format) and it's quicker for users to add a custom ObjectMapper config in their own repo rather than wait for the AL client to be updated.
  • This use case would just be a stopgap measure until the AL client got updated to properly handle the format without external help.
  • Creating a new build of the AL client isn't a slow process (at least in theory; we need someone who actually knows the release process).

[cccs-mk]

Maybe it would be sufficient to just add new constructor that doesn't accept an ObjectMapper (and then create an instance ourselves).

We could add documentation to the old constructor that says something like, "It's up to you to provide an ObjectMapper that works." At that point, though, does it still make sense for AssemblylineClient to do any configuration of the mapper?

[cccs-mk]

I've marked the ObjectMapper-accepting constructor as deprecated. It's probably safe to remove, but I don't know exactly how other people are using this library.