Passing of iter and niter in compute friction velocity subroutine

[JhanSrbinovsky]

Can implement this at a later date following implementation of:

 * In comp_friction_vel, define zetar as REAL(mp) 
 * Call comp_friction_vel with : canopy%zetar(:,iter)
 * Then we can remove iter and NITER from the definition of comp_friction_vel entirely.

if possible. For now I just want a branch to test that asymmetric dimension declaration on both sides of the CALL is not the source of fluctuation in AM3, and should be able to do that here if indeed the output is identical.

Following DM with @har917 and @ccarouge

[JhanSrbinovsky]

Note: Following outlined method of implementation will (aside from SLI issue brought up by @har917 ) require following through impact to functions psim and psis.

[har917]

Note: It is not immediately obvious scientifically why zetar and zetarsh need to be 2D arrays. It also appears that zetar and zetarsh are only partially initialised.

It maybe possible to resolve the asymmetry in dimensions without affecting the wider structure of the code - this is cetainly a good first approach since the dimension issue ripples through deine_canopy, update_zetar and the elemental functions psim and psis

[ccarouge]

In the proposed solution above, zetar dimensions only change in comp_friction_vel. The definition of canopy%zetar is not changed.

comp_friction_vel does not call psis() so why would it have an impact on psis()?
It's calling psim() but that function is already defined with an argument of dimension REAL(mp) so no change required.

And comp_friction_vel does not have any condition on SLI so there are no changes that impact SLI.

[JhanSrbinovsky]

PR - #635