Honor explicit ports in HTTPS checks

[arpitjain099]

Fixes #254

This came from https_check always building the SSLyze target with port 443 after slicing the URL string. If someone scans domain:9443, the port was not handled correctly and cert trust or chain fields ended up null.

This updates target parsing to use urlparse and pass the parsed host plus parsed port to SSLyze. When no explicit port is present, it still defaults to 443.

I also added unit tests that assert calls to with_ip_address_lookup for:

• example.com:9443 -> host example.com, port 9443
• example.com -> host example.com, port 443

I could not run pytest end-to-end in this local environment because the nassl binary fails to load (_SSLv2_method symbol issue on macOS toolchain). I still verified changes by compiling modified files and running a targeted Python harness with stubbed SSLyze modules to validate host and port parsing.

[jsf9k]

@arpitjain099 - Are the stack traces that appear when running the tests you added necessary? Is there any way to get rid of them? They misled me into thinking that tests had failed when I ran pytest locally.

[jsf9k]

@arpitjain099 - Are the stack traces that appear when running the tests you added necessary? Is there any way to get rid of them? They misled me into thinking that tests had failed when I ran pytest locally.

Hmmm...looks like the stack traces are indeed necessary because of the way that pshtt handles exceptions.

[arpitjain099]

Good catch, and they're not actually necessary - that was the test leaking pshtt's own exception logging. Both tests stop the scan early by raising from perform(), and https_check catches that and logs it with logging.exception, so the traceback printed even though the tests passed. I wrapped those calls in with self.assertLogs(level="ERROR"): so the expected error log is captured instead of printed. Pushed - output should be quiet now.