Bump to v1.5.0 and fix multiple problem instances

[jfowkes]

This is the new release PR:

• [x] signpost cache breaking in index.rst and README
• [x] open issue about cache breaking
• [x] bump to new version and date
• [x] update history.rst
• [x] rebuild documentation

We should probably switch to semantic versioning in the next release in keeping with other python packages, this has the advantage that it will allow us to bump the minor version for minor fixes which is probably a good thing.

[jfowkes]

@lindonroberts something like this? Feel free to edit as appropriate.

[jfowkes]

@lindonroberts I've hit an issue during testing with re-importing the same problem:

>>> import pycutest
>>> p = pycutest.import_problem('ROSENBR')
>>> p = pycutest.import_problem('ROSENBR')

 ** SUBROUTINE CUTEST_usetup: allocation error for CUTEST_work_global status = 5014
 Execution terminating 
>>>

This is because CUTEST_usetup is now getting called twice when CUTEStProblem is instantiated, this wasn't an issue previously as CUTEST_usetup was in the C extension module and a module can only be imported once.

A possible fix (I think) is for build_interface.py to store the current CUTEstProblem instance and just return it if the user requests the same problem (problemDir is the same) and otherwise create a new CUTEstProblem instance?

[lindonroberts]

@jfowkes - for the allocation error with CUTESTusetup, could we modify the C interface using the setupCalled variable (set to 1 after CUTEST[u|c]setup is called, then back to zero after CUTEST[u|c]terminate is called)? i.e. only call CUTEST[u|c]setup if setupCalled=0?

[jfowkes]

@lindonroberts good idea and I thought this would work, but unfortunately it seems only CUTEST_[u|c]setup returns the bounds bl,bu and initial point x that we require :disappointed:

[jfowkes]

@lindonroberts okay here is a proposed fix using a variation on the singleton design pattern, what do you think?

Edit: apparently this is sometimes called the multiton design pattern in object oriented parlance.