anchor.diff:  
   ** *Example 3:* imagine bandwidth that was created by `Bandwidth.classic(100, Refill.gready(10, Duration.ofMinutes(1)))`. +
   +
  -At the moment of config replacement it was 10 available tokens.
  +At the moment of config replacement, it was 10 available tokens.
   +
  -After replacing this bandwidth by following `Bandwidth.classic(20, Refill.gready(10, Duration.ofMinutes(1))))`, and after replacement we will have 10 available tokens.
  +After replacing this bandwidth by following `Bandwidth.classic(20, Refill.gready(10, Duration.ofMinutes(1))))`, and after replacement, we will have 10 available tokens.
  
positive.code: .There are following rules for bandwidth identifiers:
  * By default bandwidth has <b>null</b> identifier.
  * null value of identifier equals to another null value if and only if there is only one bandwidth with null identifier.
  * If identifier for bandwidth is specified then it must has unique in the bucket. Bucket does not allow to create several bandwidth with same ID.
  
  ==== TokensInheritanceStrategy explanation
  *TokensInheritanceStrategy* specifies the rules for inheritance of available tokens during configuration replacement process.
  
negative.code:     .build();
  bucket.replaceConfiguration(newConfiguration, TokensInheritanceStrategy.AS_IS);
  ----
  It is obvious that a simple strategy - copying tokens by bandwidth index will not work well in this case, because it highly depends on order in which bandwidths were mentioned in new and previous configuration.
  
  ==== Taking control over replacement process via bandwidth identifiers
  Instead of inventing the backward magic Bucket4j provides to you ability to deap control of this process by specifying identifiers for bandwidth,
  so in case of multiple bandwidth configuration replacement code can copy available tokens by bandwidth ID. So it is better to rewrite code above as following:
  [source, java]
  ----
  Bucket bucket = Bucket.builder()
  