Add customizable key to disable checks customization for certain checks

[EMaksy]

Description

This PR is one of the first steps to enable users to customize checks.
It adds a new key "customization" for checks. By default all checks with values are customization.
In order to disable this behavior it needs to be explicitly set to false .
This is needed to disable checks like 3A59DC as changing it's value may cause issues.

To Do:

After merging this we need to update tlint repo reference to the new reference.

[coveralls]

coverage: 97.338%. remained the same
when pulling 31535bf on add_customizable_key
into 84f0e0e on main.

[nelsonkopliku]

Thanks Eugen, just a couple of comments.

[arbulu89]

@EMaksy One comment.
I see that the customizable field is check wide.
This means, that you cannot make one value customizable and other not.
Did you consider adding this field to the values entries?

[EMaksy]

@arbulu89 just reworked that part 👍 and added additional docs

[nelsonkopliku]

Noice! Just a couple of adjustments.

[nelsonkopliku]

Suggested change

	When both levels are set, the **global** flag takes **precedence**, overriding any value-level customizability.
	When customization is globally disabled for a check, that is it has been marked with `customizable: false`, it overrides any values specifics, otherwise specific values customizability is considered.

[EMaksy]

I split it up into two sentences. I hope this is a bit easier for the reader :)

[arbulu89]

@arbulu89 just reworked that part 👍 and added additional docs

But do we need both versions (general and value specific)?
Because if the specific one overrides the other, I don't know if we really need the general one

Edit: Anyway, up to you. Having both satisfies what I commented as well

[EMaksy]

@arbulu89
The main reason for having the customizable field at both the top level and the value level is to provide control over whether a value is scalar or not. This allows a check to has values that are not permitted to be modified.
@nelsonkopliku please feel free to add or correct me 👍

[arbulu89]

@arbulu89 The main reason for having the customizable field at both the top level and the value level is to provide control over whether a value is scalar or not. This allows a check to has values that are not permitted to be modified. @nelsonkopliku please feel free to add or correct me 👍

The thing to enable things that are not permitted looks like a conundrum XD
Either way, if arrays and maps are not permitted to change, but in the same moment are permitted to change...
just force explicitily to the user to put customizable: false in those entries, removing any real logic that auto-detects this I guess.

[nelsonkopliku]

Let's go with this initial version