feat: optional rule to detect (heuristically) hardcoded password

[jossef]

add new rule with id hardcoded-password. This is to resolve cases like #80 .
in addition, change arguments to the following:

usage example:

--ignore-rule -> all default rules, except $
--rule -> no default rules, include $

--add-special-rule -> add non-default rule to the running rules

[baruchiro]

I did some research about how gitleaks is handling our case of password=user123, and how it avoids false-positives.

gitleaks is searching for patterns when words like password, key, api, and more, are become before a string (regex: [0-9a-z\-_.=]{10,150}).

Using 3 ways to avoid FP:

1. Searching for suspicious secrets longer than 10 characters.
2. Using "Stop Words"- a long list of words that if they are found inside the secret, the secret is considered as a placeholder and not as a real password.
3. Using ⁠Shannon Entropy to calculate the "randomization" of a suspicious secret, assuming that a secret will not be a regular string written by a human. Currently, the entropy is 3.5.
   

Question

Can we say that we are doing our best effort to find secrets, and if the user using a short obvious password like user123 it is not an important password or it is our limitation to not find any string?

If not, I will reuse this rule with lower boundaries to find a lot of suspicious strings with more false-positives.