Allow real argument to order of modified_bessel_x_kind

Newest Description

The derivatives are here https://dlmf.nist.gov/10.15 (functions themselves are here: https://dlmf.nist.gov/10.2)

The Stan functions are these: https://github.com/stan-dev/math/blob/develop/stan/math/prim/fun/bessel_first_kind.hpp and https://github.com/stan-dev/math/blob/develop/stan/math/prim/fun/bessel_second_kind.hpp

All the stuff below was the process of getting to this issue, so I'm leaving it, though it's probably confusing and should just be ignored.

New Description (Outdated)

Edit: I'm making a new description for this issue. The old description is below (so the comments make sense).

If we can make our var work with Boost Real (requirements here: https://www.boost.org/doc/libs/1_74_0/libs/math/doc/html/math_toolkit/real_concepts.html), then we can maybe autodiff the Boost modified_bessel_x_kind functions and allow real arguments to modified_bessel_first_kind and modified_bessel_second_kind.

Not 100% sure this would work, but it's worth experimenting with.

Old Description (Outdated)

The bessel functions in the math library only support integer orders:
https://github.com/stan-dev/math/blob/develop/stan/math/prim/fun/bessel_first_kind.hpp
https://github.com/stan-dev/math/blob/develop/stan/math/prim/fun/bessel_second_kind.hpp

I was doing doc for the log_modified_bessel_first_kind and it has a non-integer first argument:
https://github.com/stan-dev/math/blob/develop/stan/math/prim/fun/log_modified_bessel_first_kind.hpp

Are we limited to integer arguments in the first couple things for autodiff reasons? Or should we switch those to doubles? Boost apparently supports non-integer arguments (though it uses a different algorithm for them).

Also there are std implementations now:
https://en.cppreference.com/w/cpp/numeric/special_functions/cyl_bessel_k
https://en.cppreference.com/w/cpp/numeric/special_functions/cyl_neumann

Is there any reason to not try to switch to non-integer order arguments and use to the std implementation? I feel like I remember a performance problem in threading caused by switching a fancy math function like this once, so I wanted to ask before I opened a pull.

@bgoodri, @wds15

Current Version:

v3.3.0

Start by reading stan/math/prim/fun/bessel_first_kind.hpp, stan/math/prim/fun/bessel_second_kind.hpp, and stan/math/prim/fun/log_modified_bessel_first_kind.hpp, then review the linked Boost Real requirements and DLMF derivative definitions. Determine the design needed for real orders and autodiff support; done means the supported modified Bessel functions accept real arguments with the required derivatives and coverage.