I think you should be able to detect it quite reliably by knowing the electrical properties of the pins. USB hosts pull the DP and DN data lines low with 15kOhm resistance. USB devices pull the DP line (DN line if it's a slow speed device) to 3 volts with a 1.5K resistance. If the device at the other end pulls up and also you pull up, nothing would happen because the device doesn't react to the extra pull-up. So you could use this to check if the other end starts to send packets to the bus.
I suggest a procedure something like this:
You could start by pulling the DN line weakly high (with something like 200K to 1M resistor). You could detect a pull-down on the DN line to give a first hint that there's a host at the other side.
Then measure the VBUS, if it's high, it's a further indication that there is a host at the other side. If so, activate a 1.5k pull-up (to 3 volts) on the DP line and listen for incoming packets. If there actually is a host on the other side, it will issue a bus reset and send a GET_DESCRIPTOR packet to the bus. If this happens, you know that the other chip is a host. I suggest to do it in this order as if there's a device at the other side, it will not react to the DP pull-up.
If nothing happens, there may be a device at the other side. Release your DP pull-up and see if it's still pulled up at the other side. If that is so, then there is probably a self-powered device at the other side. If not, then start driving the VBUS line to 5 volts. At this time at the latest you should see the device's 1.5k pull-up tp 3 volts on the DP line. If you see instead 3 volts in the DN line, then there's a slow speed device such as a keyboard or a mouse at the other side.
Now act as a host and issue a BUS RESET and GET DESCRIPTOR : DEVICE DESCRIPTOR to address 0, endpoint 0. The device should now answer and finally at this point you know for sure that there is a usb device at the other end. If you haven't enabled your 5V drive to VBUS so far, I suggest that you enable it now. Test with all the devices you intend to support.
Ok, this is a hack, and the official bus doesn't work this way because if both ends would work like this then it would be a matter of luck (timing) if it detects correctly or not. But if the other end is a well-behaving USB entity, then I think that it should work. I've done a fair bit of work on the USB, but not this exact thing.
Best Answer
The USB can either be in device mode or in OTG mode. You cannot have OTG on the same USB bus as a host like a computer.
Multiple OTG devices can switch between host & device mode using "HNP" (Host negotiation protocol) but you can't do that with a pure host.
You would need two separate USB busses - one between the PC and the PIC, and one between the PIC and the devices. I don't think there is any PIC device that has 2 distinct USB interfaces.
I would suggest using a second device along side the PIC32 to act as a USB device to connect to the PC, and use the PIC32's USB in OTG mode to talk to the devices. This other device could be as simple as a FTDI chip to talk to the PIC32 through RS232, or something more powerful like another PIC (maybe a PIC18 with USB support) so you can talk through other protocols like I²C or SPI.