I think you need some background on the RADIUS Remote Authentication Dial In User Service) protocol to understand its role in authentication.
RADIUS was originally developed and deployed to authenticate (and authorize and account user access-- features I'm not going to talk about here) users dialing-in to modem pools. Envision a pool of modems accepting incoming calls and a database containing credentials of users authorized to dial-in. RADIUS is the protocol that allowed the hardware running the modem pool to offload authentication requests to a server, thus freeing-up the modem pool hardware from having to have any "knowledge" of credentials (and authentication policy, etc).
The mechanics of the protocol involve the RADIUS server (that is, the server that performs the allowed/denied authentication of the user) receiving requests from the RADIUS client (that is, the modem pool hardware receiving an incoming call) on behalf of the user dialing-in.
The RADIUS protocol is reasonably general, and has been adapted for use in 802.1x and other protocols requiring authentication. That's why you're seeing a lot of references to "network authentication". Nonetheless, RADIUS being a general protocol you could very well have an application that supports authenticating users via the RADIUS protocol. In that case, the application is the RADIUS client. The RADIUS server (the Windows NPS service) will need to be told the IP address that the application will be sending its RADIUS requests from as the RADIUS client IP address.
The RADIUS protocol requires a shared secret value (called the Authenticator) to validate that incoming requests really are coming from an authorized client (and not just some attacker trying to use the RADIUS server to brute-force passwords). Likewise, the authenticator is used by RADIUS clients to validate that responses are really coming from the RADIUS server (and not an attacker spoofing the server's identity). You will also need to configure this value.
You will need to configure the Windows NPS service with a policy to support the required authentication protocol (PAP, as you state) that the application requires. The Windows NPS service doesn't have any configuration relating to "LDAP" because it uses Windows' built-in authentication APIs, which back-end to Active Directory. Basically, you get authentication against Active Directory "for free" by using the Windows NPS service.
Be sure to check out the Wikipedia article on RADIUS for more in-depth information about the protocol, and Microsoft's documentation for the NPS service for background on configuring the Windows Server side.
Edit:
Here's the feeling I'm getting.
I found this Seimens "Security Module" documentation that describes configuration of RADIUS authentication for some of their "security integrated" Ethernet products. These things look like little firewalls, with IPSEC, NAT, etc.
I suspect that the "Security Configuration Tool" is used to configure the "security modules". To upload configurations to the security module (and, no doubt, to perform other administrative activities) a user would need to authenticate to the security module. This is where the RADIUS configuration appears to come in.
The diagram on page 80 of that document looks like exactly what I'd expect-- user authentication to the security module is forwarded to the RADIUS server, which returns an allow/deny decision to the security module. The client computer isn't involved in the RADIUS portion of the authentication at all.
It looks fairly straightforward, albeit I say that having had a lot of experience using RADIUS. Insofar as the particulars of using the Microsoft NPS RADIUS server (and your query re: "...dial-up, VPN, Wireless and Wired...") all I can say is that I'd eschew using an "Wizard" to configure the NPS service and walk thru the configuration manually. Again, having had a lot of experience with RADIUS this just looks like an exercise in trial-and-error to me, but it's probably going to be a bit more daunting to you. I definitely can't give you a click-for-click "recipe" because I don't have one of these devices available to me (though I'd love to see one-- it looks like it would be fun to do a security assessment of them).