Autoload shared libraries

[pviscone]

When a conifer JSON model is loaded conifer is not able to load also the conifer_bridge.so shared libraries (if they were already produced).

This implies:

1. The user must run .compile() every time
2. Every time that the model is re-compiled a new shared library with a different timestamp is created and a new dict is appended in the metadata list in the model JSON

This PR tries to fix this behavior by looking for the shared library with the last timestamp present in the metadata. It looks for it in the same folder of the JSON if the is not specified by the user.
It works for both the xilinx and cpp backends.

[thesps]

Thanks for this feature, it makes sense to have. I’ve left code comments in review. You should also add some tests that touch this functionality in tests/test_save_load.py

[pviscone]

Ok, I have applied all the comments.

1. I created a load_shared_library method in ModelBase that does nothing but is overloaded in the backends that need to load a shared library.
2. Now shared_library can be a bool or a string:

If True, the shared library will be looked for in the same directory as the JSON file, using the timestamp of the last metadata entry available
If False, the shared library will not be loaded
If a string, it could be:
    - path to the shared library to load for the model
    - path to the directory where to look for the .so file, using the timestamp of the last metadata entry available
    
No shared library will be loaded if a new configuration is provided

[thesps]

I think the code changes for the library reloading are now good, but I'd like to see more tests:

• split the test into some test functions that aim to test only this functionality
• test some of the expected behaviour explicitly, not only the prediction results (e.g. check the name of the loaded library)
• test different combinations of the arguments

[thesps]

Did you get a chance to resolve the comments above RE more robust testing?

[pviscone]

I have replaced the abspath with basename since a simple check on the .so file name is enough (if the entire path is wrong it will throw an error later when it tries to run the inference)