Convert all existing examples and tests to use the new additional equality/inequality constraints

[moorepants]

We now have support for adding extra constraint equations (both equality and inequality), thus we no longer need hacks for these features. All examples and unit tests should be updated to take advantage of the new features.

[Peter230655]

I will start on the examples in examples-gallery in a few days. I am not aware of hacks in the test functions, so I will start with my examples.

[Peter230655]

Unless explicit eom_bounds are given, it is still assumed that the eom = 0 ?
2.
I am trying to get the example plot_particle_in_tube converted to inequalities, away from the hacks. This is a hard-to-converge example with hacks, and so far no success in getting it to converge without them. You may recall, that plot_car_in_garage also took longer to converge without hacks.

[moorepants]

1. Yes, you have to explicitly provide inequality bounds.
2. Using eom_bounds ensures that IPOPT is used in the expected way for specifying inequalities on the constraints. If setting equality constraints + state bounds somehow causes IPOPT to solve the problem faster, then you'd need to talk with the IPOPT people about why that may be. We should align the examples in opty to use the correct underlying IPOPT interface, i.e. eom_bounds.

[Peter230655]

Clear

I am not being critical.
Since this is a new feature I feel I should report whatever I notice.
NB: it does converge now. I will push it within the next few days.

[Peter230655]

I think, in my examples the hacks have been removed, and the changes were pushed.
As #450 is pending, some state variables remain, which should properly not be state variables, but unknown input trajectories

[Peter230655]

We can now enforce instance_constraints with input trajectories, where before this was not possible - unless I am mistaken.
@moorepants There are simulations where we have state variables just to enforce some instance constraint. Should I change these examples to be as 'correct' as possible? (for me no problem, but a lot of looking / merging for you!).
25-05-18 Update:
As it seems that input trajectories converge considerably faster than state variables, I changed and pushed most of them.

I think, once we can do time derivatives of input trajectories we should be fine as far as these hacks are concerned.