Adding new mappings in pagetable doesn't require TLB flushes

[TSnake41]

Currently, MappedPageTable and similar facilities always return MapperFlush when mapping a new page, and return a error is a mapping already exist.

According to Intel specifications, adding new mappings to a pagetable doesn't require a TLB flush.

If a paging-structure entry is modified to change the P flag from 0 to 1, no invalidation is necessary. This is
because no TLB entry or paging-structure cache entry is created with information from a paging-structure entry
in which the P flag is 0.

Although, for that to be correct, we still need to ensure that the pagetable entry is actually written at the end of the mapping function (currently, this is somehow enforced by the expected tlb flush that does inline asm invlpg without the nomem attribute), otherwise the compiler is allowed to do surprising reordering of the pagetable modification to e.g after the use of the mapping we're looking to make.

[Freax13]

Interesting point. We could remove the MapperFlush from the return value, but I'm also not completely sure that we can rule out that it's not useful for some people. I think, technically, it would be safe to skip flushing the TLB on unmap operations and always flush it on map operations instead. I'm not sure if there are any good reasons to do so, but there could also be other use cases.