Possible memory leak with BoundaryFactory::add

[ZedThree]

Currently, we add new boundary conditions (and modifiers and parallel BCs) in the BoundaryFactory constructor like so:

add(new BoundaryFoo(), "foo");

If there is already something in BoundaryFactory::opmap named "foo", add emits a warning and returns. Unfortunately, this causes a memory leak as the new BoundaryFoo never gets deleted.

Now, this will never happen in the main library unless we're being particularly stupid, but it could happen in user code, especially if we end up exposing the factory through python or whatever. Trying to be as permissive as reasonable and defensive as possible makes this slightly tricky to fix. We can't just delete the passed in pointer if there's a name-clash, in case the user didn't create it with new. We could return an error code or throw an exception and except the user to clean up themselves, but this makes calling BoundaryFactory::add "correctly" quite ugly and verbose.

After some discussion with @d7919, a better solution might be to actually store std::shared_ptrs in the maps. This should take care of lifetime issues, but would change the interface. Something for 5.0?

[bendudson]

Agree std::shared_ptr would be good. Perhaps we could add a new BoundaryFactory::add() which takes a shared_ptr. The old add() function could be changed to wrap what it's given in a shared pointer, and marked deprecated.