Adding httpx as a library minimal example

[Mzack9999]

Description

This PR contains updated documentation with a minimal example of how to use httpx as a library and an integration test.
The runner API needs a major rework to separate the execution logic from gologger/goflags/CLI dependency. The following changes would be required and will be handled into independent follow-up tickets:

• Input stream via channel
• Adding context support (hence support for cancelation/deadline/timeout)
• Output stream via channel

[jimen0]

Hi @Mzack9999 - Does this PR mean there will be a major version bump for httpx? This is a public facing API change:

- func (options *Options) validateOptions() {
+ func (options *Options) ValidateOptions() error {

Please, note any wrapped error returned from an exported method automatically becomes part of your API.

	if options.matchContentLength, err = stringz.StringToSliceInt(options.OutputMatchContentLength); err != nil {
- 		gologger.Fatal().Msgf("Invalid value for match content length option: %s\n", err)
+ 		return errors.Wrap(err, "Invalid value for match content length option")

Do you want stringz package errors to become part of httpx/runner API? It sounds more like an internal package instead.

Happy to beta-test the new httpx public API once it's ready before a new version is tagged, by the way!

[Mzack9999]

@jimen0 Thanks for having a look at this. I intended to expose validation errors to the caller, as the runner might be embedded into third-party code.
To make it more usable, I think some part needs to be refactored since now the whole structure is built around the concept of a command-line tool, so indeed, I'm sure there will be a significant version bump. As this is a big task, I opted for closing this issue with a basic demo example of how to run the current version within go code and later handle significant changes into separate issues since I think the changes and refactoring will require some work.
I listed a few things I think can be a good starting point in my first comment at #670 (comment). Happy to discuss if you think we can approach the problem differently or if there are better practical ways to expose the public runner's API.