Extend Bert support

[degenfabian]

Description

The current implementation of BERT only implements MaskedLanguageModelling and has a certain number of other limitations, like only being able to take tokens as input or only supporting the model "bert-base-cased". This PR intends to enhance the BERT support of TransformerLens by addressing these limitations.

Features added include:

• Next Sentence Prediction
• Accepting strings and lists of strings as input and not only tokens
• Directly return human-readable predictions instead of only logits
• Support for Bert models "bert-base-uncased", "bert-large-uncased", "bert-large-cased"

I also extensively added and edited documentation and the existing BERT notebook.

There is no specific issue attached to this PR.

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

Checklist:

• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have not rewritten tests relating to key interfaces which would affect backward compatibility

[bryce13950]

Is there anything that can be done to simplify this return type? This function could return 5 different states, and the worst part of that is that two of the potential states are the exact same type of data, but in different shapes. I understand that they will be used in completely different contexts, but it's for that reason that I am kind of wondering why we don't do a bit more with this, and create two distinct modules for the two different use cases. All of the shared functionality could be put into components that are used in both, and it may simply be easier to communicate the usage to end users if they are distinct. The real question is, is there any use case where someone will be using both use cases with the same instance of the module? If there is a valid use case for when that may happen, then leaving it as is is probably fine. However, if it's probably not going to happen, I think I would prefer to find a way to make these more simple and single purpose.