Add Support for string and []byte Inputs in QRCode Constructors

[0x5a17ed]

Hey @yeqown,

I would like to propose this PR that updates the QRCode constructors to accept both string and []byte inputs.

While the library itself already supports handling data in byte-mode encoding (EncModeByte), the existing constructors required callers to pass a string, leading to unnecessary conversions when working with raw byte data.

The new constructors use a simple generic constraint (~string | ~[]byte) in order to stay backwards-compatible with downstream consumers of this library and a helper function to normalize inputs to []byte data. Internally, build now operates solely on raw bytes. The sourceText field appeared to be unused except for tests and thus has been removed in favor of the sourceRawBytes field that is consumed everywhere in the code internally in order to avoid duplication.

Test code has been updated accordingly, and a minor formatting change was made to the debugging logging I couldn't avoid because my code editor just kept reformatting that file, sorry for that.

Hope you like it!

[yeqown]

I've upgraded all go.mod to go1.19, please rebase code to retry workflow

[0x5a17ed]

Ah, thanks for catching that oversight of mine. I completely forgot to check if the codebase is actually targeting a go version that supports the generics syntax, which I should have done before even thinking about making my changes.

I've rebased my changes on the latest commit on the upstream main repository and also have taken the liberty to refactor the toBytes function a little bit to make it simpler.