fix memory leaks

[tarunKoyalwar]

Context

• Due to improper config or changes in config or someother scenario multiple fastdialer are created on demand
• Every time new instance of fastdialer is created all entries are load from hosts file and stored in selected storage backend
• in retryablehttp-go we were using fastdialer memory backend and multiple calls due to different scenarios caused hosts file to be loaded multiple lines (and if hosts file is large it caused a mem leak/over consumption of memory and crash nuclei or cause init to take too long (see: Nuclei version 3.x large memory allocation due to /etc/hosts entries. nuclei#4632 )
• ref: reuse fastdialer + bump go retryablehttp-go#198

Proposed Changes

• seperate host file and dns cache logic
• make hostsfile hmap shared /global and is initialized on demand
• finalizer cleans up any temporary files created by hmap in hybrid mode
• add env vars to tweak behaviour

MAX_DNS_CACHE_SIZE=10MB # current default
HF_MAX_HOSTS=4096 # hosts file max hosts to load in memory
HF_LOAD_ALL=false # when true uses hybrid backend instead and loads all entries from hosts file

• added max dns cache size on memory backend
• now we use either memory or hybrid backend for dns cache / hostsFile data

[Mzack9999]

LGTM - Good redesign against possible fastdialer misuses.

A note about the original implementation: the intention was to leave up to the caller the duty or declaring fastdialer as a singleton instance and pass it along with a global reference. Generally it's the canonical choice also for other similar libraries such as net/http where there isn't a shared client used by all instances. The hosts file permanent caching was left out from a global shared kv, as a sort of mimicking the behavior of the hosts file which is read everytime there is a network lookup, so that new declarations of fastdialer could somehow still benefit from potentially refreshed values (assuming that the caller creating a new instance would have desired the most up to date versions of the file)